Who give me a Descriptor ID?
 

Each servent must to have a Descriptor ID, right? But how can I get it?

Thanks.

Use a random number generator. If you are using Linux, just read 16 bytes from /dev/urandom.
There are some plans, however, to make this GUID tag more descriptive.
See http://rfc-gnutella.sourceforge.net/...ID-Tagging.htm
for details.

Guido

Thank you, Guido

interested in VB-Code?
 

hi, here's "my" code for this "problem"... should even be understood by C programmers ;)


Public Function GetRandomGUID() As String

Dim intIndex As Integer

Randomize Timer
For intIndex = 1 To 16
GetRandomGUID = GetRandomGUID + Chr$(CInt(Rnd * 255))
Next
End Function

CU

search getguid in the msdn there's a source code

Specifically, there is a Windows API function called "CoCreateGUID".

Whether you use the Windows API function or generate a string of random numbers, either way is just as easy.

Message ID: A 16-byte string uniquely identifying the message
on the network.

Servants SHOULD 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 modern servant.

Servants SHOULD initially store all 0's in byte 15 of
the GUID. This is reserved for future use.

The other bytes SHOULD have random values.


Don't mess it up with the Servant identifier in Query Hit and Push messages.

Servant Identifier. A 16-byte string uniquely identifying the responding servant on the network. This SHOULD be constant for all Query Hit messages emitted by a servant and is typically some function of the servant's network address. The servant Identifier is mainly used for routing the Push Message

... limewire
 

hi,
this is just a limewire proposal and as far as i know it isn't used beacause all these things can be done with the 0.6 handshake.


here some lines (0.6 specification):
.......
Lime Wire LLC had proposed using the GUIDs of initial ping requests as
a form of protocol versioning. For example, the last byte of the GUID
of the first message by a client would be 0 if the client spoke the
"Gnutella 0.5" protocol, 1 if the client spoke the "Gnutella 0.6"
protocol, etc. While this scheme is backwards- compatible, it is
imperfect. First, it does not provide ways for clients to support
different combinations of protocol extensions. If, for example,
clients at the "0.6" level were to support QRP and pong-caching, a
servent would be required to implement both. Second, this scheme
places a burden on the servent implementer. For example, a servent
trying to accept only connections with QRP support must put new
connections on "probation" until it has received the initial ping.
.......

CU