Re: DHT vs Gnutella

Quoting Angel Leon <[email protected]> from ml.gnutella.dev-forum:
:In the case of FrostWire, we'd be looking to use it only to store magnet
:alt-locs,
:and perform all magnet searches via the DHT, pretty much what the freebase
:script does, but all in our clients. So I guess my question is, why bother
:implementing
:a new DHT for this purpose instead of using mojito-dht?

Because the Mojito DHT is a general-purpose DHT that does not define
how things get published, in which format, and when.

BTW, gtk-gnutella is now able (since 19:48 today, Paris time) to join the
Mojito DHT and can issue node lookups.  My servent even says:

	DHT averaged global size estimate: 371329

which is not bad, although I suspect it's grossly over-estimated.

The questions I have now are:

* How do I publish my SHA1?
* How do firewalled servents publish their push-proxies

and more importantly:

* How can I read other-people's SHA1 and push-proxies?
* How to make sure others can find and read what I publish.

The current documentation I have on Mojito (obviously this is a parallel
impelementation as everything in gtk-gnutella is done in C...) gives me
no clues whatsoever about the data architecture.

Also, I have trouble understanding what the "secondary keys" are.

Raphael

P.S: Some statistics about node lookups, showing the elapsed time for the
lookup to reach a termination point and the traffic (in and out) generated
for each:

	38.785600 secs, hops=17, in=10905 bytes, out=3807 bytes
	54.039890 secs, hops=22, in=14540 bytes, out=5346 bytes
	53.869495 secs, hops=18, in=10905 bytes, out=4131 bytes
	53.616663 secs, hops=21, in=13086 bytes, out=4860 bytes
	45.903455 secs, hops=15, in=8724 bytes, out=3321 bytes
	60.915373 secs, hops=22, in=14540 bytes, out=5346 bytes
	51.073746 secs, hops=9, in=4362 bytes, out=1863 bytes
	52.676033 secs, hops=19, in=11632 bytes, out=4212 bytes
	52.878718 secs, hops=22, in=14540 bytes, out=5346 bytes

These were "bucket refresh" node lookups in foreign buckets away from my
closest subtree.  I use alpha=3 and loose parallelism (i.e. the next batch
of alpha requests is sent out as soon as one of the outstanding RPCs
comes back).