Purely P2P OT is potentially infeasible for collaborations that are extremely long live and that have large numbers of collaborators. I included some rationale below.
That said, I can't imagine a use case where mobile devices will really do OT with each other without a server. Unless we are talking OT over bluetooth, there is typically a server still involved to act as a mediator between mobile devices. There are not any truly P2P mobile apps. A VERY OVERSIMPLIFIED RATIONALE In many P2P OT instances each client maintains its own operation counter (1, 2, 3, 4) that is incremented each time an operation is generated. When it creates an operation it sends along its counter in an array. The array contains its operation counter, and the information it has on all other participants counters. This is called the context vector. One might look like this: <1, 4, 17, 2, 5> Assuming there are 5 collaborators. The next time I receive an operations from participant 3 (currently with 17 in the context vector) maybe his count is now 19, I update my context vector to be: <1, 4, 19, 2, 5> When I send an operation I sent it with this context vector. You can see that if there are a lot of collaborators over time the context vector gets VERY big. You have to send this with EVERY operations. Maintaining this state and sending it over the wire is inefficient. Like I said this is an oversimplification. The real scenario is actually worse. For better or worse, Wave's algorithm was designed to remove this issue. Other ways to mitigate this are interesting areas of research. ~Michael On 6/12/13 5:11 PM, "Pratik Paranjape" <pratikparanj...@gmail.com> wrote: >Thanks for the link Michael. Having a look. I really think we should go >HTTP. I thought of a model where two wave servers simply act as >participant >in a different "system" wave, communicating over same protocol and tool >set. Riding our own horse instead of new external protocol. DNS can help >for resolving. I will see if I can elaborate on that. > >To clarify about P2P: I understand wanting to have p2p in the sense that >SMTP is...servers do work sort of p2p, no central node. But clients don't. >We do not have little email servers in our devices. > >If I have understood correctly some of us have shown interest in having >truly p2p communication between clients, including data and OT. I think >this was the way some wavewatchers wanted to go. This is different than >"server" p2p. I was wondering how many of think its technically feasible >and want to go that way. > > >On Wed, Jun 12, 2013 at 9:21 PM, Pratik Paranjape ><pratikparanj...@gmail.com >> wrote: > >> Has anyone actually thought over how it will be possible for something >> like wave to be P2P over HTTP? With security and data replication >> requirements? I don't see it myself :) Is this a direction many of us >>are >> thinking (technically) about? >> >> >> >> >> On Wed, Jun 12, 2013 at 9:10 PM, Pratik Paranjape < >> pratikparanj...@gmail.com> wrote: >> >>> XMPP is what making servers federate in current code Bruno. Setting up >>> prosody etc... >>> >>> http://wave-protocol.googlecode.com/hg/spec/federation/wavespec.html >>> >>> >>> On Wed, Jun 12, 2013 at 8:53 PM, Bruno Gonzalez (aka stenyak) < >>> sten...@gmail.com> wrote: >>> >>>> Is XMPP involved in the connection of Mobile devices in wiab or the >>>> defunct >>>> google wave? >>>> Or are you thinking about a future when wave has already become a P2P >>>> software? >>>> >>>> >>>> On Wed, Jun 12, 2013 at 5:16 PM, Michael MacFadden < >>>> michael.macfad...@gmail.com> wrote: >>>> >>>> > The general consensus was that XMPP had to much overhead to be >>>> practical >>>> > in anything theory than highly connected environments for lively >>>> > collaboration. As bandwidth trails off, and/or you don't have >>>> persistent >>>> > TCP connections (I.e. Mobile devices). XMPP was killing the ability >>>> for >>>> > lively collaboration. >>>> > >>>> > On 6/12/13 3:02 PM, "Dave" <w...@glark.co.uk> wrote: >>>> > >>>> > >On 12/06/13 14:48, Yuri Z wrote: >>>> > >> But without XMPP you would need to define your own discovery >>>> protocol. >>>> > > >>>> > >Yes. And implement alternatives for a couple of other bits such as >>>> > >stream encryption, and anti-spoofing (such as dialback). >>>> > > >>>> > >Nothing particularly tricky, although personally I don't think it's >>>> > >worthwhile. There's a lot of XMPP specs and implementations that we >>>> > >don't use, and our use of XMPP might be unusual, but I don't think >>>> it's >>>> > >unreasonable. >>>> > > >>>> > > >>>> > >Dave >>>> > >>>> > >>>> > >>>> >>>> >>>> -- >>>> Saludos, >>>> Bruno González >>>> >>>> _______________________________________________ >>>> Jabber: stenyak AT gmail.com >>>> http://www.stenyak.com >>>> >>> >>> >>
