Last Friday, December 05, ~stevenf did a ...social experiment with SubEthaEdit. Sadly none of us CodingMonkeys was aware of this, or we surely would have joined the document.
The aftermath is very nice to read. Here is the last readable state of the document.
I can offer some explanations about the load on the network SubEthaEdit causes. First you have to understand that the real bottleneck is the connection of the one that hosts the document, as every change made to the document makes it's way through the SubEthaEdit of the host.
If H is host, A B C D and E are connected to one document, then the flow of events is as follows:
B makes a change, that change is sent to H, H applies the change, and then sends it out to A C D and E. So it's really the upstream of H that gets quite filled. If n is the number of participants, then you'r outgoing traffic is (n-2) times the incoming traffic plus (n-1) times the thing you change yourself. Quite much. So running a SubEthaEdit "server" that should host more than a couple of users behind some asymmetric line is not a good idea. Because as the upstream gets filled, downstream also stalls because of tcp/ip failing. (Anyone that has tried filesharing systems behind a DSL line without limiting the upstream is very aware of this :-) ). SubEthaEdit will improve on the data-size of an average change, but this main fact won't change as it is inherent in the design.
Has there been any thought to harnessing the various casual P2P stuff out there in some form or another -- taking advantage of direct connections when they exist? I suppose the problem would then be that one user could introduce corruption through bugs or malicious intent, but they can already do that. The WASTE model for a small P2P network comes to mind as a rather nifty way of doing it.
Posted by: Richard Soderberg at 12.12.03 17:14