On Mon, Feb 22, 2010 at 9:50 PM, Jochen Bekmann <[email protected]> wrote: > Hi Torben, > > On Mon, Feb 22, 2010 at 8:51 PM, Torben Weis <[email protected]> wrote: >> Hi Anthony, >> >> I see three serious problems here: >> a) Resubmitting a delta does not always work IMHO because there are no IDs >> or Sequence numbers. We touched this topic already when discussing error >> recovery. The conclusion was that comparing deltas is Google's suggested >> approach to detecting duplicates (i.e. resubmissions), but it is not 100% >> safe and cumbersome. I assume this is a lost battle, but the approach is >> systematically flawed for no good reason. I propose to send a tuple of >> epoch&sequence-number with each submit to reliably and easily detect >> resubmissions by remote wave servers and by clients. > > This is not a lost battle, I have taken up the debate with my > colleagues to add back (we did have one at some point) such a token. > We have not had time to fully debate this issue, but there is a fair > chance that we'll address this in the next revision. > >> b) Imagine the following scenario: '->' means 'sent to': S->R->C, where C is >> a client, S a wave server and R a remote wave server. Let's assume that S >> sent a wavelet update but no commit-notice. R has already forwarded the >> wavelet update to C. After a timeout, R concludes that S has crashed. Now it >> has to tell C that the uncommitted wavelet update must be revoked. >> This tremendously increases the complexity of wave clients and wave servers. >> Is it worth the pain? The only thing commit-notice is optimizing for is >> "delay". At the same time bandwidth is reduced (commit notice must be sent). > > Yes, the protocol is more complicated with a commit notice. Because > we've made an emphasis on low latency we felt the trade-off was > acceptable. I'd note that where Anthony wrote "committed to disk" > means "reliably committed", for some level of reliability - and > depending on how reliable you want (what if a server's local disk > fails, or a RAID array, a consensus amount database backends etc..)
correction: "do you need a consensus amongst database backends or a RAID array etc..?" > there can be more than a trivial amount of time involved. In practice > the commit notice is not a large overhead as it covers a number of > deltas that were previously submitted. The commit notice originates > from the c/s protocol, and I guess one could remove it from the > federation protocol and make servers only communicate changes once > they have committed. However, it would mean federated clients and > servers would be less responsive that the ones we have already > implemented. > >> c) The current C/S protocol is not able to handle deltas that have been sent >> to the client and are revoked later (see previous example). We really need >> the new C/S protocol. > > The client in FedOne does not do many things, as we have acknowledged. > We truly are working on getting a full client/server protocol out. We > will post more details on our timeline in the next week. > > regards, > Jochen > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
