On Thu, 17 Mar 2005 22:57:06 -0500, Colin Putney <cputney at wiresong.ca>  
wrote:
> Interesting. I hadn't considered that assertions about the same U might  
> be coming from different nodes. Do we also have to deal with the  
> possibility that two different people will be making different  
> assertions about U at the same time?
>
Define 'same time'... In distributed systems, that's hard enough without  
parts of your network moving at relativistic speeds ;).

The software doesn't forbid it. But it is highly unlikely. First - the DGV  
project and MC have in common that it has lots more write than read  
transactions; writing is relatively rare. Then, there's an awful lot of  
information out there, the chance that two people work on the same bit is  
small, the chance that they do this at the same time is smaller, and the  
chance that whatever they do results in the same low-level assertions is  
even smaller.

The whole philosophy behind this project is that things can go wrong. You  
can either have simple software that goes wrong because it doesn't try to  
patch all the issues of distributed computing, or you can have very  
complex software that manages to take into account all of Deutsch's  
Fallacies and account for them. In the latter case you may have  
transactions that take days to resolve and bugs that follow from sheer  
complexity. So I'm clearly aiming for the first case here ;).

Gossip has time synchronisation built in now. So it can always make an  
educated guess about what transaction was later (plus or minus 5 seconds,  
say). It is a very trivial synchronisation system, but it seems to work as  
long as you don't want second precision. And as long as you aren't  
interested in the wall-clock time, because nodes let their 'network clock'  
drift to adjust for what their neighbours think it should be.


> It's a different bandwidth and latency tradeoff, but it should work.
>
Yup. And in Gossip, presence announcements have an origin, so you don't  
even need to broadcast; one could directly start to chat with the origin.


> Right. Also, if the "clock comparison" strategy turns out to be better  
> than "chatty ancestry" we can probably manage to do clock comparison  
> only between peers, and not require every node to track the clock of  
> every other node.
>
It definitely is simpler :). Probably a matter of taking the simplest  
thing and keeping a tab on the number of times that conflicts arise. I  
really really wouldn't know how often this would happen...

>> Lots of verbosity and thinking aloud - but did I understand you  
>> correctly here, Colin?
>
> Yes.
>
Kewlness :). I'll try to make a stab at this stuff for the DGV project,  
then.