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..) 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.
