obby should be a true peer to peer architecture

[spamfaenger@…]

Hi there,

when using Gobby, we often have the problem that one of the gobby-peers is the server and has to quit, while the rest of the users would want to go on editing.

This is quite annoying as the only way to achieve this is, to close the session (loosing all change marks) and reopening the document on a different peer where the others then all reconnect.

All the while it is my understanding that the basis of the obby merging algorithm was designed to work in a peer to peer environment, so it should be no problem to do this (from an algorithmic standpoint).

Several solutions come to mind:

• Promote a new server if the old one quits, so the centralised model can be retained (probably a bit less code)
• Go completely decentralized, that is, make it a peer to peer network where each gobby instance is its own 'servent' and connecting to one of the instances makes one connect to the network. This is probably a lot more work, though it seems conceptually a lot cleaner.

Well.... Thats my two cents. :)

[armin]

You have noticed the possibility to save a complete session (including change markers), haven't you?

Automatically selecting a new server is pretty complicated because on the on side it has to be clear which client will be the new server (since after the host left, all communication channels are gone) and on the other side, the new server might have another document state as the original server and/or others, so a resync to any client would be necessary (or some magic to find out what is already there).

Implementing a complete peer-to-peer system is not supported by the current architecture and would require some not-so-easy re-designs and re-implementations. This will most probably not happen in the near feature since neither Phil nor I do have the time for such big changes currently.

[anonymous]

Replying to armin:

You have noticed the possibility to save a complete session (including change markers), haven't you?

Yes I have. However it doesn't help that much if the server quits unexpectedly, either by crashing, or because he didn't announce it carefully enough.

Automatically selecting a new server is pretty complicated because on the on side it has to be clear which client will be the new server (since after the host left, all communication channels are gone) and on the other side, the new server might have another document state as the original server and/or others, so a resync to any client would be necessary (or some magic to find out what is already there).

I see your problems, however it is my understanding, that two peers with the same vector time should be interchangeable as servers.

Implementing a complete peer-to-peer system is not supported by the current architecture and would require some not-so-easy re-designs and re-implementations. This will most probably not happen in the near feature since neither Phil nor I do have the time for such big changes currently.

To bad. :) But I alreaddy thought so. Perhaps in one of the next rewrites. (I guess there would be some pretty hard science involved in getting something like that to work.)

[kardan]

Automatically selecting a new server is pretty complicated because on the on side it has to be clear which client will be the new server
(since after the host left, all communication channels are gone)

There could be a list of successor's changeable by the actual server or all. The first one in the list could hold a backup of communication data which the server just had to update on dis-/connects. So real p2p functionality would not be necessary and notwithstanding the session would not be lost an sudden disconnects of the server.

[anonymous]

Replying to kardan:

There could be a list of successor's changeable by the actual server or all. The first one in the list could hold a backup of communication data which the server just had to update on dis-/connects. So real p2p functionality would not be necessary and notwithstanding the session would not be lost an sudden disconnects of the server.

I was thinking about this again. Well, there is the problem of finding the one Server with the most recent state, so nothing gets lost. However finding a new coordinator isn't so hard. For example, one could simply use a buddy-algorithm.

[armin]

The current collaboration algorithm (jupiter) does not support real p2p functionality, so we would have to keep the centralized model out of that reason anyway.

I was thinking about this again. Well, there is the problem of finding the one Server with the most recent state, so nothing gets lost.

Thing is, there is no server with "the most recent state". Several time may have passed until the participants notify that the server went done in which all of them might have altered the document. It would be required to somehow "merge" these changes when a new server has been found. I don't see a possibility to do this with the current collaboration algorithm, so a resynchronization would have to be performed, losing each but the server's changes since the disconnect occured.

Implementing such a feature would result in the same as if of the remaining participants serialized the (disconnected) sessions and reopens it as a new server, so I don't think it is worth the effort.