What is the maximum size of the udp packet which is sent by the mainline DHT node for the get_peers query?

Question

What is the maximum size of the udp packet which is sent by the mainline DHT node for the get_peers query? How does the node response when it store 3000 peers? (the packet is very large in that case). How does the mainline DHT client handle it's response?

Thank you in advance.

Answer 1

Just like any bittorrent tracker, the response does not have to contain every peer, just a random selection.

The most popular clients (I can really only speak for uT, BTML and libtorrent-rasterbar) has an assumed MTU size which they try to not exceed. The assumed MTU size is somewhere below 1500 bytes (which is the typical max ethernet frame size), this is typically the upper end of the path MTUs you would see on the internet as well. It's typically a good idea to shave off a few tens of bytes from that, to cover for connections run over PPPoE and other transports like that.

When sending packets over IPv6, care need to be taken to use an even lower MTU if it's over Teredo (1280 bytes), none of these clients I mentioned supports DHT over IPv6 yet though.

To be precise, uTorrent assumes an MTU of 1500 - 20 bytes of IP header - 8 bytes of UDP -header - 24 bytes of potential GRE header - 8 bytes for potential PPPoE header - 2 bytes for potential MPPE header. i.e. 1438 bytes of UDP payload.

Even if your packets exceed the path MTU, the IP layer will fragment them and merge them at the endpoint, transparent to the bittorrent client.

Answer 2

For the IPv6 DHT an upper limit of 1024 bytes has been defined, see http://bittorrent.org/beps/bep_0032.html

As for the values list (the peers returned), the node simply should return a randomized subset that fits into the packet size, not the full list.

Note that IPv6 does not support en-route fragmentation. So if one wanted to send larger packets then the sender either has to conservatively fragment the packets (which decreases reliability) or implement socket error handling and resends in userspace since UDP sockets do not do that automatically, unlike TCP. To avoid those complexities and inefficiencies it is best to just squeeze the variable-sized data in a packet down until it fits into the prescribed size.