Vinnie:
Quote:
|
In any event, the GUID on pings and pongs doesn't really matter, since these messages are no longer routed.
|
It's true that cached pongs are no longer routed, but the GUID does matter for some still though (I still feel we need to backward keep compatibility in mind for a while longer).
This is what I do when I return cached pongs:
-- Set the GUID to that of the received PING
-- Set the TTL to Hops + 1 of the PING (ie, Hops = 0 -> TTL = 1, Hops = 4 -> TTL = 5) I noticed from Gnutellian it varies a lot in your case
Gnutellian:
Most clients these days don't look at the GUID of pongs anymore. They they will just store any pong that passes by. This will cause their host cache to fill up faster, and without less frequent ping. This is part of the ping/pong caching, not just LimeWires, but many variants.
The GUID of all zeroes also ensures that in most cases, the pong can't be routed anymore because you wouldn't have a matching routing table. Personally, I would find it more elegant if the TTL/Hops was used insetad, but I have done (and still am) overriding some meanings of functions as well. Specifically, the ConnectBack feature (which, although recommended by someone else, would be replaced by an updated version).
This didn't occur to me before, because I wasn't aware Vinnie was actually doing this though, and the varying TTL/Hops trhew me off too.