Hi,
there are two things I would like to comment/change in LW's Gnutella proposals, handshake upwards compatibilty [1] and branding superpeers 'ultrapeers' [2].

About v0.6 handshake upwards compatibility. A client should not respond with "GNUTELLA/0.6 200 OK" when a v0.7 client (or above) connects. Instead it should respond with "GNUTELLA/0.6 501 Not Implemented". A sample handshake (taken from my v0.7 proposal, plz adjust to v0.6 needs!):

About "Ultrapeer". There has been no need IMHO to brand superpeers 'ultrapeers'. Can we just forget about marketing and name them simply 'Superpeers' or 'Superservants' please. :-) Only the name 'Supernode' is trademarked (Kazaa/Morpheus/Grokster use only this term on their webpages, eDonkey uses the term 'server'), everything else is free. AFAIK good old Clip2 was first mentioning superpeers or refelectors.

Hope you like it, Moak

[1] Gnutella v0.6 Handshake - http://groups.yahoo.com/group/the_gd...Gnutella06.txt
[2] "Ultra"peers - http://groups.yahoo.com/group/the_gd...ltrapeers.html (Yahoo account required)

What advantages would that have over 0.6? When you receive a "GNUTELLA/0.6 200 OK" to a "GNUTELLA CONNECT/0.7" you will know that 0.7 is not implemented and, if you want, you can terminate the connection, if you wanted to prefer hosts that implemented the newer protocol.

An OK is not an answer when you do not support the protocol.
Rather than evaluating the protocol of the opponent, the opponent should give a correct answers: "Not implemented", plus the supported protocol versions (see header above) for further handshake.

Well, some feedback from Limewire would be nice. Something like "no, we don't like it" or "it's not a good idea".

Thx, Moak

Moak!

The easiest way to get an anwser is to send a PM!

Send the link to afisk, I am sure he will reply!

Morgwen

I don't think that this "requery"-type of acknowledgement is a good idea for downward compatibility.
User Agents should autoconfigure themselves by specifying the best protocol level they can manage, as it is the case for the HTTP protocol itself (when it autoconfigures between HTTP/1.0 and HTTP/1.1)

So the client sends its own protocol level, and the server only needs to answer back by specifying a supported protocol level lower than or equal to the client protocol level. The server then should not use any extension above this level, and can assume that the client is compatible with that reduced level (if it was not the case, it would mean that this protocol is not downward compatible). The server should not use any extension protocol not supported by the original version specified by the client.

When the client receives back the answer from the server, it knows immediately if it supports its own protocol, or if the server downgraded the protocol level. Then the client should restrict to only use any subset of the protocol specified by the server answer. If the server answer specifies a version for which there is no discriminating code in the client, the client should only use the subset specified by a previous or core version.

So the common protocol version is immediately determined by the first CONNECT query, and by the server answer. There's no need to aknowledge versions once more: both the client and the server know the exact version of each other's protocol, and both are restricted to use only a subset of the protocol determined by the lower of these two version numbers.

However, the protocol should include a OPTIONS query type, like for HTTP or FTP, to avoid mandatory support of optional components in order to support a given protocol level: such options could be the support of proxying download ports and the support of "proxy-download-port" search types

I commented such a proxying option within a previous submission, in order to better support NAT-routed clients, without requiring SOCKS capabilities in both the NAT-router, and the connecting client, and without requiring its explicit support within all UltraPeers or within all nodes in the Gnutella Network (in fact this capability is only needed in the proxy-demanding client and in the proxy-capable peer). In such a configuration, proxy-demanding clients do not share directly their files to the network or to the UltraPeer, but instead use a dedicated incoming connection to a proxying agent which can cache the requested files, however proxy-demanding (NAT-routed) agents do actually publish their files using their own host key. This change only makes the same proxying agent (identified by its own IP on Internet) support downloads for files shared with different host keys (so that a single IP would map different host keys).
For legal reasons, however, the proxying agent should discriminate its own host key from the host keys of its connected NAT-routed agents: this is performed when the proxying server connects to the network, because it will initially only publish its own IP, prior to spray searchable files from its connected agents.

And for the safety of the network, UltraPeers should not be the only allowed agents that support proxying, but this capability should be made automatically accessible for lower-range agents which have a moderate connection speed or connection time and thus are not electable to act as UltraPeers. Because these proxying-capable clients will be most often connected to an UltraPeer, there may be a need for this UltraPeer to test if this connectected Agent is capable of acting as a download proxy. This test should use the basic "search" query, but with a well-known and recognizable query extension to identify "dowload-port-search" query strings.