On Tue, Feb 23, 2010 at 06:02, Torben Weis <[email protected]> wrote: > 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.
Yes. It requires that the remote server still has a bit of state - it needs to match up the response saying "need a certificate" with the original request to resend it. > 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. I'd look at it a different way - that the server hosting the wave should be stateless. > 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 Note that they only need to fetch the signer info once for a given signer. It might be a useful extension to the getSigner request to allow multiple signers to be fetched in a single request/response, though. > 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. But they're going to be able to do that anyway, with or without the signatures being bundled with the history response. > 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. The problem I have is the notion of "new" is non-obvious. What you really want is "signer info that I haven't seen yet". So far, we've really tried hard to make the remote wave servers do the heavy lifting - it's up to them to request things of the hosting wave server. This seems like it would scale better. > 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]. >> 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. > -- 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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
