Vinnie:

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.

Just wanted to point out that the "Connect Back" feature is actually unnecessary...the original 0.4 Gnutella protocol specification is sufficient!

I had *great* results with BearShare by just advertising pongs when I want a connect back.

This is how we implemented auto-detect of firewalled status.

BearShare lets loose with pongs for up to 1 full minute (per hour). If it gets "ins" then we aren't firewalled, else we are firewalled.

You can see the state transitions in BearShare 3.0.0 by putting the cursor over the Hosts LED and observing the messages in the balloon; e.g. "Ponging for incoming connections"

Also, the Network balloon shows some other states, like the firewalled detection progress.

BearShare 2.6.x has these features as well, but lacks the enhanced feedback in the indicator area.

I highly recommend anyone who is interested in implementing connect-back features seriously think about just using pongs to entice other servents into providing a connect back.

Sorry for seeming like a maniac about It Vinnie, but...

I'm writing a servant, and don't have a staff of developers, it's just me...

As far as the 'Routed Pong' issue, I am following the specs outlined in:

http://www.limewire.com/index.jsp/pingpong

as well as general guidance from:

http://cvs.sourceforge.net/cgi-bin/v...ella/Draft.txt

Earlier in the thread, I myself even stated that it made the identification of pongs easier. I finally(prior to Vinnies posts)
had actually stopped looking at the MsgID in received pongs and just cached them if (TTL>1 and TTL <= MAX_TTL) and (hops > 0 and hops <= MAX_TTL) in an effort to get around this 'anomally'.

Hey, no blood, no foul.

Goodness, just noticed the many typos I made in my previous post.

I like the idea of simply using pings/pongs for firewall detection (by looking at any incoming connections as a response), but how long does that take though? And are you setting the "firewalled" status per connection, or globally? Just curious. The ConnectBack for supporting clients usually takes less than a few seconds.

Fortunately, I didn't.

Its like greased lightning. Try it yourself:
http://download.bearshare.com/BSTEST300b52.exe

Eh? The firewalled status applies to the local servent, not per connection. The status is tested when the first host is connected, and reset when the last host drops. It is also re-tested once per hour, in case their firewalled status changes.

You may not believe it, but user's firewalled status can actually change from hour to hour. Not only that, but they can get different IP addresses, and we re-detect that every hour too.

How? By establishing a few outgoing connections even though we don't need them. Its easy enough to 503 a 0.6 handshake on the 3rd set of headers even if you're outgoing. The Remote-IP does the job.

This even works to detect cases where their IP address changes due to DHCP, and they are using NAT.

A small number of users complained that they were becoming firewalled even though they knew they weren't. In EVERY case, it was user error, they had indeed become firewalled.

Yeah but its so much cooler to implement it in a way that even works with the original Gnutella 0.53 servent.

You're doing fine then. Some problems end up taking longer to solve than they should. Thats just how the cookie crumbles.

But the good news is, there are lots of seasoned Gnutella developers eager to help (myself included).

Looks like you found some.

Actually, I set the firewalled status per connection. Reason being if the Gnutella client is used within a larger network. For example, a school campus. It may be that incoming connections from the Internet are firewalled, but local connections (from dorm to dorm) are not. It's just a small thing though, but it would prevent any unnecesary "push" requests, as we all have noticed can sometimes not work as advertised among different versions (different developers).

If you want to support that feature, then why dont you just use the MIB and get a list of interfaces along with subnet masks?