…

Peter Dimov wrote:

Hi David,

[1]. If you feel that QUuid won’t do, then stick to your UInt128. Later we can think about generalizing the concept into a generic class for ints of random length. Btw although not documented, QUuid has public member variables data1, data2, data3 and data4 and they can be accessed. In Gnutella each packet has a GUID in the header for which QUuid is used and I thought it may be suitable for Kad as well.

That is another option which will allow support for 160 bit numbers, which might be interesting. On the other hand, maybe we could subclass QUuid and add specific methods like XOR, distance,…

[2] I mean the doxygen documentation in the header for the class PeerInfoPacket. In the header for each template instantiation just write “See PeerInfoPacket” in the Payload description part.

Got it, you’re absolutely right.

Further questions:

3. Do you know how similar are the packets of Kad, eDonkey, eMule, etc? Maybe the template classes can take the Protocol as a template argument as well. If I got it right they all have the same header at least and I would guess the payloads may not be too different.

Yes, there is a header for UDP packets and another one for TCP packets. Currently Kad uses only UDP. I think eDonkey is using both UDP and TCP for different purposes… I think the packets for eDonkey are not very similar after taking a look into them (the definition file from amule is attached to this post).

4. There was also something with an additional payloadLength header field for packets sent over TCP. For UDP the payload length can be calculated from the UDP datagram size. For which protocol was that? Maybe the packet factory could handle this as well?

Those are TCP packets.
Regards,

David