On 2/26/10, Daniel Paull <[email protected]> wrote: > I agree with your comments about trusted/untrusted partitioning. > However, I would like us all to examine cient/server interaction as > well as server/server interaction. Even sticking with the current > architecture, satisfying TP2 in the client/server protocol has > advantages, such as: > > 1) The removal of the server acknowledgement, leading to lower latency > between clients
The server acknowledgements aren't related to the lack of TP2. In fact, OT systems without TP2 (which is essentially all two-party OT algorithms) typically don't use server acknowledgements. Our transform algorithm would still work well if we didn't have server acknowledgements. The decision to put in server acknowledgements (and slightly decrease the liveness of waves) was based on considerations not related to the choice of transform algorithm. > 2) Trivial "recovery" algorithms as the server can, after a rollback, > get operations back from clients Shifting the responsibility for reliability from a trusted server to other clients seems like a questionable solution. I think reliably storing the server's data shouldn't be the job of clients. > 3) Relaxed durability requirements. Because of (2), the server can > promise less. Now we can remove the horrid commit-notice message. It seems to me that farming out responsibility for storing data to other clients doesn't really give any guarantees that your data is being reliably stored. I'm not a suitable person to comment on commit-notice itself (although I did have some pretty strong opinions regarding commit-notice when it came up for internal debate) so I'll refrain from doing so. > 4) Intention preservation that actually preserves intent. I'm not sure I know what you mean here. Every multi-party algorithm designed to satisfy TP2 can also be used as a two-party algorithm. But not every two-party algorithm can be used as a multi-party algorithm. The algorithms that can be used when TP2 is not required is a superset of algorithms that can be used when TP2 is required. That means two-party algorithms can always be at least as good at intention preservation as multi-party algorithms. In fact, two-party algorithms often have nicer intention preservation properties than algorithms that satisfy TP2, because they're unencumbered by the requirement to satisfy TP2. I think algorithms which satisfy TP2 in order to work as a distributed algorithm tend to be considerably more complicated, have less elegant transforms, have slightly less desirable behaviour, or result in operations which are uglier and more verbose. But if you can demonstrate otherwise, that would definitely be of interest to us. Here are some other considerations: A lot of Wave is built around the notion that there is a single universal history where all the operations have a total ordering. This is useful for features like playback (among some other more minor features). In a peer-to-peer algorithm, it's a lot less natural to define a single universal history. Another consideration is that the version vector in a distributed algorithm might become very large in size if you have hundreds or thousands of participants. Maybe there are good ways to mitigate this, but please take into account that this is a vector you'd be sending with every operation (even tiny single-character operations). > There is hack upon hack in Wave that is trying to compensate for the > lack of TP2 satisfaction. Wouldn't it be nice to undo all of this and > solve the problems properly? > > > Cheers, > > Dan > > On Feb 26, 6:00 am, Tad Glines <[email protected]> wrote: >> I think TP2 could be made to work if federation where separated into two >> security domains (trusted and non-trusted). Federation between severs that >> trust each other and have agreed to apply access control policy >> consistently >> could allow TP2. But federation between non trusted servers would need to >> disallow TP2. >> >> -Tad >> >> >> >> On Thu, Feb 25, 2010 at 12:35 PM, Torben Weis <[email protected]> >> wrote: >> > Tad, I fully agree. >> >> > TP2 leads us to the area of peer-to-peer. My team at University has >> > spent >> > the last three years on solving some security problems that arise when >> > running an MMOG like WoW on a peer-to-peer system without any central >> > authority. The algorithms are very complex and many of them eat up a >> > decent >> > amount of bandwidth. It will take some additional research years to >> > reach a >> > level of trust comparable to that of a centralized MMOG. >> >> > Based on this experience, I cannot imagine that Wave (which is not >> > research, but a productive system) will be ported to TP2. However, from >> > a >> > scientific point of view it might be interesting to explore the >> > potential >> > benefits of a TP2-based wave. >> >> > Greetings >> > Torben >> >> > 2010/2/25 Tad Glines <[email protected]> >> >> >> There's been some discussion about wave and how things would be much >> >> better if wave supported TP2. >> >> >> Currently all deltas must be sent to the wavelet host, or owner, for >> >> transformation before the delta can be propagated to all other wavelet >> >> readers. This means that Wave doesn't support the OT property TP2. If >> >> wave >> >> supported TP2, then there would be no need for a wavelet "owner" and >> >> each >> >> server could arrive at the consistent wavelet state independent of each >> >> other. Put another way: without TP2, the wavelet "owner" is the single >> >> point >> >> of failure. With TP2, there is no single point of failure, and no >> >> "owner". >> >> And there's the problem, no owner means no control. >> >> >> In order for wave to be successful there needs to be a wavelet "owner". >> >> The "owner" can enforce schemas and enforce access control policies. If >> >> wave >> >> supported TP2, then it would be impossible for a server to prevent a >> >> another >> >> server from writing to the wavelet. One could expect all the servers to >> >> "play nice together" but there is no way to explicitly enforce access >> >> control policies in a TP2 environment when the servers are owned and >> >> operated by separate entities. >> >> >> -Tad >> >> >> -- >> >> 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%2bunsubscr...@goog >> >> legroups.com> >> >> . >> >> For more options, visit this group at >> >>http://groups.google.com/group/wave-protocol?hl=en. >> >> > -- >> > --------------------------- >> > Prof. Torben Weis >> > Universitaet Duisburg-Essen >> > [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%2bunsubscr...@goog >> > legroups.com> >> > . >> > 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. > > -- 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.
