> > > Let's consider the case where servers A, B and C are participating in a > wave > > using the peer-to-peer propagation model. When server A generates a delta > it > > will sends that delta to servers B and C. Server C cannot prevent server > A > > from sending deltas to server B. It can reject deltas from server A but > this > > prevent convergence and eventially it would no longer be able to > participate > > because it's version of the wave would deviate too much from the version > > that A and B contain. > > Aren't they all servers that you trust and want them all to converge? > Can you give a more specific case that you are worried about? I > struggle to understand how this network could be established (ie, why > did servers accept connections) if they did not want to exchange > operations. >
I think some of the confusion surrounds what we each mean by "server". In all my past e-mails, when I said server (e.g. host server, remote server, etc...), I was referring to a single wave domain (e.g. acmewave.com, wave.google.com, etc...). From the point of view of Wave federation and wave OT, the federation host, or federation remote is refered to as a server (in the code anyway). In actual implementations the "server" would likely be a cluster of physical server. In my example above you could replace A, B and C with A.com, B.com and C.com. > > > 2) Simpler protocol as there is none of this sever ack guff > > > > Server's will still need to communicate successful receipt of deltas. > > The TCP ACK is sufficient though. > No, it's not. Just because a TCP packet has been ACK'ed does NOT mean that the application has actually read the data out of the TCP recieve buffer. Not does it mean that the application has finished parsing the message and reliably done anything with it. > > 6) Branching and merging of data in an arbitrary manner > > > > Branching and merging is still possible without TP2. > > No it's not. You're turn. > Perhaps we are thinking of two different things here, but, as fas as I can tell, it is already possible to branch the history of a wavelet, and then merge changes from one branch to another. I plan to test this, but it's not at the top of my task list right now. > > > > 7) Distributing the OT load across multiple servers > > > > This already happens. Each wavelet will need to be procesed on only one > > machine concurrently, but thousands of wavelets can be processed on > > thousands of servers concurrently. > > So, by "Distributing the OT load across multiple servers" you mean > "putting the OT load for a given wavelet on a single server at any > point in time"? You still have fundamental problems - let's sat that > all 100,000 users all tried to edit the same wavelet. How do you > distribute the the OT load? You can't. You're stuffed. With TP2 in > the mix, you have multiple server take the load. The secret is to > reduce the fan-in (ie, number of connections) on each server. > Frankly, I think 100,000 users all contributing to a single wavelet at the same time is an extreme example. I'm not aware of ANY collaborative system that supports 100,000 users concurrently modifying the same item. Also, each machine will still have to process the deltas from all 100,000 users. Otherwise there is no way to arrive at a consistent state. This is true for the clients as well. each client in a 100,000 user wave, will have to process the deltas from all 100,000 users. TP2 doesn't magically reduce the number of transforms that will need to be applied. It just relaxes ordering requirements. -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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
