主线DHT节点为get_peers查询发送的udp数据包的最大大小是多少？
主线DHT节点为get_peers查询发送的udp数据包的最大大小是多少？ 当节点存储 3000 个对等点时，它如何响应？ （在这种情况下数据包非常大）。 主线 DHT 客户端如何处理其响应？
先感谢您。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就像任何 BitTorrent 跟踪器一样，响应不必包含每个对等点，而只是随机选择。
最受欢迎的客户端（我实际上只能代表 uT、BTML 和 libtorrent-rasterbar）有一个假定的 MTU 大小，他们尽量不超过这个大小。假设的 MTU 大小低于 1500 字节（这是典型的最大以太网帧大小），这通常也是您在互联网上看到的路径 MTU 的上限。通常最好从中削减几十个字节，以覆盖通过 PPPoE 和其他类似传输运行的连接。
通过 IPv6 发送数据包时，如果通过 Teredo（1280 字节）发送数据包，则需要注意使用更低的 MTU，但我提到的这些客户端都不支持 IPv6 上的 DHT。
准确地说，uTorrent 假定 MTU 为 1500 - 20 字节的 IP 标头 - 8 字节的 UDP 标头 - 24 字节的潜在 GRE 标头 - 8 个字节用于潜在的 PPPoE 标头 - 2 个字节用于潜在 MPPE 标头。即 1438 字节的 UDP 负载。
即使您的数据包超过路径 MTU，IP 层也会将它们分段并在端点合并它们，这对 BitTorrent 客户端是透明的。
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.
对于 IPv6 DHT，已定义 1024 字节的上限，请参阅 http://bittorrent.org/beps /bep_0032.html
至于值列表（返回的对等点），节点只需返回适合数据包大小的随机子集，而不是完整列表。
请注意，IPv6 不支持路由分段。因此，如果想要发送较大的数据包，那么发送方要么必须保守地对数据包进行分段（这会降低可靠性），要么实施套接字错误处理并在用户空间中重新发送，因为与 TCP 不同，UDP 套接字不会自动执行此操作。为了避免这些复杂性和低效率，最好只是压缩数据包中可变大小的数据，直到它适合规定的大小。
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.