Hi,
I'm just wondering what Gnutella clients do if you send them a
packet of a type that they don't recognise - i.e. the payload
descriptor is not one of the standard ones.
I can see that servants should be able to manipulate the TTL
and the hops then pass the packet on, simply ignoring it
themselves.
There's nothing mentioned in the protocol (or the version I'm
using) so I'm wondering what current clients do.
Also, what sort of extensions have been thought of so far? I've
got an idea for one but I'm still not entirely sure how it should
work

Thanks,
John

clients that receive an unknown packet are likely to drop the connection.

This is why the 'bye' proposal for a new packet can be done as the last packet.

John,

If the message has a descriptor that is unrecognized, ie. 0xFF, then the client may think it is out of sync. Some client will drop you right away, some will attempt to get back in sync (my client does that by sending out a ping, then look for a pong in the data stream).

There's a number of them now. One of them is called "HUGE" which provides file hashes in search results, and resource locators. This opens up a whole new range of possibilities.

Another one is called "GGEP". This one allows you to add additional data to the QueryHit and Query packets (and actually others too). This additional data could almost be anything you can think of, considering the current limitations of Gnutella (like the size of a message). GGEP is built such so not to break older clients.

You should be able to find this, and many other proposed additions at the GDF (Gnutella Developers Forum) at http://groups.yahoo.com/group/the_gdf. Unfortunately, you are required to have a Yahoo! account to access this site (although getting such account is free).

-- Mike

It's funny actually. I've written a small client myself and when I checked back on it I found that my client uses the type as a method to keep in sync. If it doesn't recognise the type it closes the connection.
I have seen the_gdf and have started posting to it, about Time Sensitive Data.
John

I've seen that topic, and I've been commenting on it. Great idea!

-- Mike