Каков максимальный размер пакета udp, отправляемого основным DHT-узлом для запроса get_peers?

Question

Каков максимальный размер пакета udp, отправляемого основным DHT-узлом для запроса get_peers? Как реагирует узел, когда он хранит 3000 пиров? (в этом случае пакет очень большой). Как основной клиент DHT обрабатывает свой ответ?

Заранее спасибо.

Answer 1

Как и любой битррент-трекер, ответ не должен содержать каждого пира, только случайный выбор.

Наиболее популярные клиенты (я могу говорить только о uT, BTML и libtorrent-rasterbar) имеют предполагаемый размер MTU, который они стараются не превышать. Предполагаемый размер MTU находится где-то ниже 1500 байт (это типичный максимальный размер кадра Ethernet), обычно это верхний предел MTU пути, который вы также увидите в Интернете. Обычно хорошей идеей будет сократить от этого несколько десятков байтов, чтобы покрыть соединения, работающие через PPPoE и другие типы транспорта.

При отправке пакетов по IPv6 необходимо соблюдать осторожность, чтобы использовать еще более низкий MTU, если он превышает Teredo (1280 байт), хотя ни один из упомянутых мною клиентов еще не поддерживает DHT через IPv6.

Чтобы быть точным, uTorrent предполагает MTU 1500 - 20 байтов заголовка IP - 8 байтов заголовка UDP - 24 байта потенциала Заголовок GRE - 8 байтов для потенциала Заголовок PPPoE - 2 байта для потенциального заголовок MPPE . т.е. 1438 байт полезной нагрузки UDP.

Даже если ваши пакеты превышают MTU пути, уровень IP фрагментирует их и объединяет их в конечной точке, прозрачной для клиента bittorrent.

Answer 2

Для IPv6 DHT был определен верхний предел в 1024 байта, см. http://bittorrent.org/beps/bep_0032.html

Что касается списка значений (возвращенные одноранговые узлы), то узел просто должен возвращать рандомизированное подмножество, которое соответствует размеру пакета, а не полному списку.

Обратите внимание, что IPv6 не поддерживает фрагментацию на маршруте. Таким образом, если кто-то хочет отправить большие пакеты, то отправитель должен либо консервативно фрагментировать пакеты (что снижает надежность), либо реализовать обработку ошибок сокетов и повторно отправлять их в пространстве пользователя, поскольку сокеты UDP не делают этого автоматически, в отличие от TCP. Чтобы избежать этих сложностей и неэффективности, лучше всего просто сжать данные переменного размера в пакете до тех пор, пока они не поместятся в предписанный размер.