Flavio, Thanks for your quick response. in the case of 2 out of 3 write,
If all 3 copies get corrupted on the wire, we can't do much, also verifying checksum on the bookie can be a huge performance hit (unless we are using on chip checksum of x86, a different topic but I think we should use them). My question is do we recover from out of placement of these entries if one copy gets corrupted on the wire? May be, Given that we have duplicate ledgerId and entryIds on the wire, we can compare them on bookie. This can be simple and gives double the protection. May be question/discussion is how(if we are) do we recover from wrong placement of entryId on one of the bookies? - At the recovery time - At the read time - At the continual operation scenario, bookie writes entryId 4 as 5, and what happens when it receives real entryId 5? Do we need to open an issue for this? Thanks, JV On Sat, Nov 28, 2015 at 7:43 AM, Flavio Junqueira <[email protected]> wrote: > Thanks for raising this question, it is a good one. The initial motivation > for the digest was to give the client the ability of checking the integrity > of the data stored and retrieved end-to-end. End-to-end means that if I get > the same thing I added, then I'm able to verify with the digest. However, > if the data is completely dropped or stored in the wrong position in a > server, then the client won't get it back from that server, so we rely on > the replication for this kind of issues. The replication won't help though > if there is an error that affects all replicas of the data, like the entry > id or the ledger id gets corrupted before the entry is sent to the > different replicas, but in this case, if the entry is stored in the wrong > position, we should be to spot via the duplicate ledger id/entry id. Also, > keep in mind that TCP has a checksum, so we get a bit more coverage for > free, but surely that alone doesn't make strong end-to-end guarantees. > > I suppose we could make a verification on the server side, and if I recall > correctly, we haven't done it for performance reasons. Perhaps some of the > other guys on this list has a different recollection. > > -Flavio > > > On 28 Nov 2015, at 04:36, Venkateswara Rao Jujjuri <[email protected]> > wrote: > > > > Here is my understanding of bookkeeper and its digest: > > > > - Client calculates the digest and inserts into the payload. > > - LedgerId, entryId are duplicated both in the non-digest on the wire > > protobuf message > > and also on the 'body' which finally gets stored on the ledger storage. > > - LedgerId and entryId from the protobuf's addRequest is directly copied > > onto to the response. > > - On Bookie, ledger storage extracts ledgerId, entryId fields from the > > 'body' *without verifying the digest.* > > > > My question is what is protecting on the wire corruption of entryId on > the > > wire before adding it to the ledger Storage/Journal? > > > > -- > > Jvrao > > --- > > First they ignore you, then they laugh at you, then they fight you, then > > you win. - Mahatma Gandhi > > -- Jvrao --- First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
