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
|