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
