light client core

[zsfelfoldi]

No description provided.

[robotally]

Vote	Count	Reviewers
👍	0
👎	0

Updated: Tue Nov 24 04:01:28 UTC 2015

[codecov-io]

Current coverage is 46.72%

Merging #1989 into develop will increase coverage by +0.05% as of 1101763

Powered by Codecov. Updated on successful CI builds.

[anthony-cros]

is the "TODO" still relevant?

[zsfelfoldi]

It is, retrieving individual receipts by tx hash doesn't work yet, only retrieving all receipts from a block by block hash. We have to add some new messages to the LES/1 protocol to cover relaying transactions and checking their status but it's still being figured out.

[zelig]

var list []*Peer
for _, p := range ps.peers {
    list = append(list, p)
}

or

list := make([]*Peer, len(ps.peers))
var i int
for _, p := range ps.peers {
   list[i]=p
   i++
}

[obscuren]

This is actually fine since append does not grow the array. Just the slice and there's no additional overhead of realloc every time append is called.

[karalabe]

One general comment. I wouldn't rename the db fields everywhere to ca. CA usually represents Certificate Authority and imho it's kind of misleading/confusing as to what it is. The db naming should be fine even if it's a "remote access thing". It conveys the idea of what it is much better vs. having to think what a ca is.

[karalabe]

I don't really see the value in this method. It just wraps the one below, gives it a weird name and provides confusion as to why the same thing can be done multiple ways. NewChainAccess(db, false) would be ihmo just fine to call from client code.

[karalabe]

The PR very heavily leaked networking/protocol primitives into the database access layer. IMHO, no notion of peers, peer sets, packets, protocols, etc should be allowed in core or core/access. Please remove these as their proper place will be in ethereum/les and simply define an interface (that ethereum most probably will implement) through which you can request the light ethereum object to fetch you some data.

The access layer in core should be simply an adapter to either a database, or a light ethereum object. It must not have a clue about how the data is retrieved by the underlying implementations. My suggestion would be to define maybe two interfaces: a full db and light db that other objects can implement. Then ethdb would implement full db, ethereum/light would implement light db. This way the LES protocol would be completely outside of core, which was the original idea behind the PR split in the first place.

[karalabe]

Don't create a new access layer every time you want to generate a chain. Pass it as a parameter instead of the db ethdb.Database. Maybe @fjl has an input on this? But IMHO if we replace the databases with accessor objects, then they should be fully replaced from their point of creation and not just wrapped at the last minute (would be very very wasteful memory wise to have a lot of small wraps deep in the code).

[karalabe]

Please gofmt your code. There are a lot of changes which broke the formatting, some introduced very weird ones actually.

[zelig]

it is thread safe to write the results because Deliver that calls this lock chainAccess including all requests sent. Please comment that caller must hold the lock over req to be used concurrently.
the same for Valid functions of all request types