Re: Re: Search by urn ??

The bootstrap is really lacking.  Really people have to have the LW source and
the message format document.  There is really not much else that is helpful.

I did patch barracuda a little to get some GGEP info from LimeWire nodes.  It
seems that a bit that is suppose to be 0/1 is actually 0/2 (active or passive).

Anyways, this is the key information for bootstrapping.  Ie, you sniff the
regular gnutella GGEP traffic for the DHT info which gives you a population of
nodes to correspond with.

I was really wishing to make gtkg a passive node so that if it is an ultra, it
would support LW leafs who are full participants in the mojito network. 
However, I was expecting the wiki to get updated.  This was last summer.

fwiw,
Bill Pringlemeir.

diff -r barracuda/src/lib/ggep.c barracuda2/src/lib/ggep.c
495a496,498
>   GGEP_ID(DHT),
>   GGEP_ID(DHTIPP),
>   GGEP_ID(TLS),
diff -r barracuda/src/lib/ggep.h barracuda2/src/lib/ggep.h
70a71,73
>   GGEP_ID_DHT,
>   GGEP_ID_DHTIPP,
>   GGEP_ID_TLS,
diff -r barracuda/src/main.c barracuda2/src/main.c
103a104
>   GPT_DHT       = 0x44,
297a299
>   case GPT_DHT:       return "DHT";
488a491,505
> static void 
> handle_ggep_dht(const char *data, size_t size)
> {
>     if (size == 3) {
>         printf(" ver: %d.%d, mode:%s", data[0], data[1],
>                data[2] ? "active" : "passive");
>     } else {
>         if(size)
>             printf(" raw data (%lu bytes): \"%s\"",
>                    (unsigned long) size, escape_buffer(data, size));
>         else
>             printf(" Unknown <No payload>");
>     }
> }
> 
537a555,556
>     case GGEP_ID_DHT:     handle_ggep_dht(data_ptr, data_len); break;
>     case GGEP_ID_TLS:     break;
1054a1074,1093
> handle_dht(const char *data, size_t size)
> {
>   if (size < 26) {
>     fprintf(stderr, "handle_push(): Too small\n");
>     return;
>   }
>   printf("ServentID: %08lx-%08lx-%08lx-%08lx\n",
>       (unsigned long) peek_be32(&data[0]),
>       (unsigned long) peek_be32(&data[4]),
>       (unsigned long) peek_be32(&data[8]),
>       (unsigned long) peek_be32(&data[12]));
>   printf("Index: %lu\n", (unsigned long) peek_le32(&data[16]));
>   printf("Target: %s\n",
>       net_addr_port_to_string(net_addr_peek_ipv4(&data[20]),
>         peek_le16(&data[24])));
> 
>   handle_extension(&data[26], size - 26);
> }
> 
> static void
1359a1399
>     case GPT_DHT:       handle_dht(payload, payload_size); break;

--- [email protected] wrote:

> Hello Sam,
> 
> Quoting Sam Berlin <[email protected]> from ml.gnutella.dev-forum:
> :See http://wiki.limewire.org/index.php?title=Mojito .  If there's
> :things missing, let us know.
> 
> Yes, this page is useless to everyone but you:
> 
> 	http://wiki.limewire.org/index.php?title=Mojito_Values
> 
> I want to know the low-level format, I don't care about a Java API when
> implemeting a servent in a non-Java language.  What matters is the
> storage representation and the architecture of the values.
> 
> Actually, I think the storage should be completely language-neutral,
> and specified the same way Gnutella messages are specified, i.e. at the
> byte level.
> 
> This page is incomplete:
> 
> 	http://wiki.limewire.org/index.php?title=MojitoDHT_Bootstrap
> 
> How do you find the first DHT node to bootstrap and send your first FIND?
> 
> This page is only useful for internal developpers and should not be
> visible from public specifications:
> 
> 	http://wiki.limewire.org/index.php?title=Ping_Sequence_Diagram
> 
> Finally, this page is not precise enough:
> 
> 	http://wiki.limewire.org/index.php?title=Mojito_Message_Format
> 
> For instance, it mentions things like "BigInteger".  What does that
> mean in terms of number of bytes, format, etc...  Saying the BigInteger
> is made of a length followed by the big integer itself, is... well...
> 
> The Contact holds a SocketAddress that can be IPV4 or IPV6.  How does
> one decompile the packet and know what to expect? (again, Endianness...)
> 
> So, to conclude, it's a good start that there is some documentation,
> but we are far from the quality of the documentation that was made for
> other important features like the ping-pong reducing scheme, a long time
> ago, or the QRP.
> 
> It is still not precise enough to start implementing anything in order
> to aim at full interoperability with LimeWire.
> 
> Raphael
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ