MC, P2P, distributed collections

Colin Putney cputney at wiresong.ca
Wed Mar 16 16:52:22 UTC 2005


Cees de Groot wrote:

[snip lots of p2p issues]

> The alternative is to have these assertions to carry 
> along some  sort of MC-like ancestry: every version gets a new UUID, and 
> versions  state what their parent is. But that would mean that these 
> assertions  would get large. As they are the glue in the whole 
> distributed information  repository and therefore quite common with 
> probably frequent updates this  could mean quite a bandwidth burden...

Actually, this is one area where the versioning model of MC2 is a big 
improvement over that of MC1. With MC2, versioning the presence 
assertions might be feasible.

With MC1 we'd essentially be slinging around a versioned list of all the 
nodes in the network. Every node would be generating its own view of the 
list, based on what it knows and constantly remerging based on what it's 
getting from other nodes. Ugly, ugly, ugly.

With MC2, each presence assertion would be versioned separately. Thus 
you'd only get new versions when some node left or joined the network, 
and you'd be able to compare it with your current notion of the status 
of the node: either it's the same version (status hasn't changed), it's 
an older version (you can discard it), or it's a newer version (you need 
to update your status)

The versioning overhead for this stuff would be pretty small - I'd 
guestimate something like 32 bytes + 24 bytes per version of ancestry. 
I'm liking more and more the idea of doing mc2 network repositories via p2p.

Colin




More information about the Squeak-dev mailing list