Without the 3rd step in connecting to a server additional requests are very hard(read, non-conform.. like the HTTP/1.0 and GNUTELLA/0.4 on the same port.) to do. Thus one could see this as a 'future guaranty' that extensions could be implemented. However what would a server do if it would get a bad(read, unknown) header? Right!, usually they disconnect. This needs to be more documented.

However you most likely do not need the additional requests because in the two headers that are send to and from the server is all the information one would probably ever need. If one could think of a request that needs to be done outside the initial 2 handshake headers, please post them here


The Uni code character sets could be negotiated in the header. However if not all clients support unicode then searches might come out wrong (or worse, block) at a given server in the network. Also unicode is 2 bytes, so it will add extra overhead on the network.

Example:

A doesnt do unicode
B does
C does

A - B - C

B needs to 'downgrade' search requests and 'upgrade' searchhits from A to B or C. This would be very hard for example chinese to standard ASCII.

Some more thought might be usefull, but I like the idea


I didnt even know about the 0xff at byte 9. It serves no real long time purpose either. New clients will simply use the new standard, and they can be just as bad at routing (read, none) and ping/pongs as the old clients. Some non-yahoo group (emailed) based paper on these GUIDs would be nice indeed.

Tam