Mike Green says:
> Nevertheless, MS Windows is generating the GUID for me, so I don't have
this
> 0xFF ninth byte.

Can you overlay the ninth and sixteenth bytes in the future? That is after,
Windows generates the GUID, just do
guid[8]=0xFF;
guid[15]=0;

This is an easy way of supporting protocol versioning. We discussed this a
long time on the GDF, and I am still hoping we can use it. For example,
LimeWire is planning on releasing an alpha version with ping/pong caching in
the not-too-distant future. For the scheme to work optimally, you need to
identify old clients. GUID versioning is the easiest way of doing that.

I agree that this has to be documented better. CLIP2: my original proposal
is attached to the end of this document. Can you add it to the appendix of
your protocol specification?

BTW: LimeWire just uses random bytes for all other values. In the absence
of a common GUID algorithm, that's as good as anything.

Christopher Rohrs
Sr. Software Engineer
LimeWire

----------------------------------------------------------------------------
-----------------
[This was written in late January 2000. The GUID marking has subsequently
been adopted by LimeWire and BearShare. For this reason, the statistics are
no longer accurate.]

Here my proposal for tagging GUID's. It's cheap, effective, and simple:

1. Clients store all 1's (0xff) in byte 8 of the GUID.
(Bytes are numbered 0-15, inclusive.) This serves to tag
the GUID as being from a new client.
2. Clients initially store all 0's in byte 15 of the GUID.
This is reserved for future use.

Why byte 8 for (1)? At least two older clients (Gnutella
0.56 and Gnotella) appear to use the Windows CoCreateGUID()
call to generate their GUID's. It appears that byte 8 of
these GUIDs are always of the form 10XXXXXX, where "1" is
the most significant bit and "X" means "don't care". This
is definitely the case if CoCreateGUID uses the algorithm
described at

http://www.ics.uci.edu/~ejw/authoring/
uuid-guid/draft-leach-uuids-guids-01.txt

A quick experiment shows that fewer than 0.05% of GUIDs
currently have 0xff in the eighth byte. And this gives us a
full byte for future use.

As an aside, note that you can place an upper bound on the
number of these older clients on the network by passively
listening to traffic and counting the number of GUID's for
which (guid[8]&0xc0)==0x80.