Hi,
> Finally, we're thinking about some improvements for the next version > for the federation protocol - in particular, bundling of signatures as > an optional part of a submit-request, > This is a good idea, since it would remove one message type (post signer) and thus reduce the complexity of the protocol. It would be nice to have a protocol that is "state-less" (just like HTTP is state-less). If anyhow possible, a protocol should be able to make a decision by looking at (1) the request and (2) the stable storage. Having to remember past statements for a bound time (i,e, transient state) should be avoided. Example: When a remote wave server receives a wavelet-update, it may realize that it has to ask first for the signer of this update and second it may need a wavelet history. For the updates in the history it may again need some signer info. Finally, we have to wait for the commit notice. Only now it is possible to commit the updates to stable storage. Thus, the remote wave server has to keep large amounts of transient data before it can commit. To illustrate this, look at the following example between wave server S and remote wave server R: S -> R: wavelet-update 40 R -> S: get signer info S -> R: signer info response R -> S: wavelet history request from version 20 to 39 S -> R: wavelet history response ... repeated several times: R -> S: get signer info S -> R: signer info response ... time goes by .... S -> R: commit notice 40 What's the problem? (1) The implementation of the protocol is more complex. One needs to handle all kinds of errors that could occur in the above conversation. (2) An attacker could (willingly or because of a bad implementation) suck up all RAM of a remote wave server. Just keep on sending wavelet-updates without signer info, or avoid sending a commit notice. I assume that many wave implementations will crash because they try to keep transient data in RAM. Clients will keep non-committed data in RAM, too. If each wavelet-update is several kbytes, all it takes is a few hundered thousand messages to fill up Gigabytes of RAM. Writing transient data on disk is not good either because an attacker could force a remote wave server to perform massive disk I/O. Well, there are ways to deal with all of it, but it is not easy and requires a lot of care. How to simplify? Imagine the following conversation between wave server S and remote wave server R: S -> R : wavelet-update for version 40 but signer info is missing and wavelet history starting at version 20 is missing R -> S: Error: Please send history from 20 to 40 S -> R: wavelet-updates from version 20 to 40 including all signer infos which are new, i.e. not required for version 1 to 19. R -> S Acknowledge The above solution is state-less. No party needs to maintain transient state. The only disadvantage is that it may send signer info that has been sent in the context of another wavelet before. Thus, there is a trade-off. I think the success of HTTP has shown that "Keep it simple stupid" is a key to success. Wave Federation should follow the KISS principle, too. If it gains traction, one can still implement some performance optimization techniques, but don't make it too complicated in the beginning. It will simply slow down the acceptance of the protocol. "No premature optimizations" :-) Cheers Torben > Thanks, > > Anthony > > -- > Anthony Baxter, [email protected] > > -- > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- 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.
