p2p monticello - any takers?

Cees de Groot cg at cdegroot.com
Sun Feb 27 02:32:51 UTC 2005


On Sat, 26 Feb 2005 22:05:02 +0100, Avi Bryant <avi.bryant at gmail.com>  
wrote:

> Yep, this sounds very cool.  Looking forward to the next post from
> Cees saying "ok, so I went ahead and implemented this, here it is..."
>
Ok, so I went ahead and implemented this, here it is...

(from the completely-untested-but-highly-interesting-code-dept.)

Avi helped me a bit on IRC, so I could hash out a skeleton implementaton  
of TPMCRepository, a Monticello rep that sits on my p2p networking code.  
Before you go off and download it, note that:

a) it is completely untested - especially the front-end bits;
b) it is completely and utterly insecure in that you don't know where a  
version comes from;
c) it will announce the complete contents of your MC package cache to the  
network, including that secret code normally only available under an NDA  
signed with blood that you're writing for your next dotcom startup.

Actually, point a) is the best security feature at the moment, because  
chances are good that the software will not be able to do any harm ;). A  
next version will sport private key signing of packages that originate  
 from your box and some yet-to-be-invented mechanism of distributing the  
public keys for signature checking out-of-band.

Anyway, what happens if you install the code:
- MCCacheRepository gets a couple of overrides to announce its stuff to  
the network. The p2p code has presence code in it which tries to  
disseminate this information over the network in what I hope is a  
relatively efficient manner (there's a clear time/bandwidth trade off  
here, of course).
- Announcements will be renewed every 24 hours as long as the file stays  
around;
- TPMCRepository, if you add it, will read the local copy of these  
announcements (which hopefully gets stuffed with refreshments fromt the  
network all the time) and show these as the repository contents.
- When you attempt to open a file, it'll ask the nodes that announced it,  
in turn, to send the file to it. If that succeeds, MC gets to do its  
thing. The file is added to the MCCacheRepository so that the next time  
around you'll have it locally (plus the side effect is that your node will  
now start announcing the file).

The goal of this thing is to see how large amounts of presence information  
can be dealt with. Most machines these days should be capable enough to  
handle very large sets of metadata pointers (MC presence info is just a  
filename and a originating peer UUID, so you should be able to keep a  
million of them around), but that will require something more scalable  
than the trivial implementations I used in the AardWorks-Gossip package.  
Maybe using the large collections will be enough, maybe some persistence  
is needed. Bandwidth usage is probably a matter of tuning rather than  
radical changes in the current approach but that's more a gut feeling than  
anything else.

If you want to look at it, grab  
http://tai42.xs4all.nl/~cg/mc/Tric-P2P-CdG.4.mcz and check the overrides  
in MCCacheRepository and the single class in Tric-P2P-MC.

If you want to play with it, fine. But send me fixes, not whines that it  
doesn't work :-P

Oh - if you have old, like pre-Friday, p2p code in your image, make sure  
to clean up any AWGPeer that is still running; I changed most timeout  
values from integers to durations, and that messes up running peers.

And BTW - if you want to help out, if nothing else, pull the code into a  
scratch image, do "AWGPeer newOnDefaultPort", iconize it, and let it  
simmer. The network currently is 2 nodes big, a bit more would be fun  
(especially nodes not behind NAT, they are a tremendous help in  
bootstrapping the network and acting as stable reference points).

Exercise for the reader: at the presence code to the chat app so we can  
take #squeak into the p2p age :)

Bedtime,

Cees



More information about the Squeak-dev mailing list