Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / UDP максимальный размер нефрагментированного пакета

UDP максимальный размер нефрагментированного пакета

g-contПостоялецwww9 июня 201814:01#0
Согласно спецификации максимальный размер пакета 65 килобайт. Причём, как я понял размер MTU учитывается только для пакетов, которым выставлен флаг фрагментации (ну или наоборот флаг, запрещающий её). Вопрос такого плана - есть некий сервер, с которого качаются ресурсы по UDP. С размером пакета в 65 килобайт. С одной клиентской машиной (провайдер билайн, роутер DlInk Dir300) без каикх-либо проблем проходят эти пакеты по 65 килобайт и соответственно с другой клиентской машины (провайдер мтс, роутер TP-Link) проходят только пакеты, равные размеру MTU. Тут еще что любопытно - в длинке размер MTU вообще невозможно поменять, попросту нет такой опции, в TP-Link наоборот опция есть, но изменение размера не влияет на проходимость больших пакетов.
Получается решение о доставке больших пакетов полностью берёт на себя роутер и эту ситуацию никак не поменять?
DampireПостоялецwww9 июня 201814:16#1
ZabПостоялецwww9 июня 201814:31#2
65 килобайт - это ты не в ту сторону округлил. Чуть меньше 64кб, на самом деле, 2 байта под длину минус затраты на заголовок пакетов.
Рассчитывать на такой размер можно только в локальной сети, да и то не всегда, иногда локальная сеть состоит из нескольких сегментов, связанных через сервер-роутер, который может быть настроен как угодно, в том числе и случайно, по причине неграмотности админов.

В современном интернете рассчитывать можно на пакеты чуть больше 1.4кб. Если нарвешься на устаревшие каналы связи, может быть еще меньше, но в том случае наверное можно послать юзера куда подальше, ремонтировать свою сеть. Шансы нарваться исчезающе малы, настолько устаревшие сети надо искать в музее.

g-contПостоялецwww9 июня 201815:30#3
Zab
ну я естественно в коде учёл реальный размер, вычел размер заголовка, перед установлением соединения всегда посылаю тестовый пакет, на клиентской стороне сверяю CRC, если не доходит, постепенно уменьшаю размер нефргаментированного пакета, пока не дойду до размера MTU. С реализацией у меня проблемы нет.
Проблема в том, что один роутер пропускает, а другой нехочет. А может дело в провайдере, хотя навряд ли.

>>Рассчитывать на такой размер можно только в локальной сети, да и то не всегда
Тем не менее через полстраны коннект на 64 килобайта у меня стабильно устанавливается. Я проводил опрос, кол-во тех, у кого проходит 64к пакет к кол-ву тех, у кого не проходит распределились в процентном соотношении 20\80. Но я пытаюсь понять где кроется ограничитель.

DelfigamerПостоялецwww9 июня 201816:05#4
1. Работать с фрагментированными датаграммами сложно и неудобно.
2. UDP-датаграммы необязательны для доставки.
1+2. Длинную UDP-датаграмму проще выбросить, чем фрагментировать.
Соответственно, если на пути между А и Б окажется хотя бы один дешёвый маршрутизатор - пакет не пройдёт.

Правка: 9 июня 2018 16:08

Ghost2Постоялецwww9 июня 201817:48#5
g-cont

Затачивай софт на 512 байт нагрузки. Ну или из расчёта на минимальный MTU в 576 байт. А reassembly проводи в софте. Маршрутизаторы могут резать трафик с флагом more fragments.

Sh.Tac.Постоялецwww9 июня 201818:27#6
g-cont
> если не доходит, постепенно уменьшаю размер нефргаментированного пакета, пока
> не дойду до размера MTU
так и делают, бит DF и вперёд : )

тут правда два момента:
1. честное PMTUD основано на ICMP пакетах, связываться с которыми иногда нет желания у разработчика/провайдера/файрвола
нужное подчеркнуть

+ Показать

2. хорошо бы гонять не пустые тестовые пакеты, а нагруженные полезными данными которые не критичны ко времени доставки

есть ещё вариант слать несколько вариантов пакетов разной длины при установлении соединения, и смотреть какие пары запрос/ответ прошли, но это не точно т.к. после установления соединения трафик может ходить и другим путём

З.Ы. ну и большие данные надо передавать не так как небольшие : )
т.е. огульно слать всё в надежде что может быть оно когда-нибудь соберётся полностью на той стороне, плохая идея
лучше аккуратно слать очередной кусок и смотреть дошло-не-дошло
https://gafferongames.com/post/sending_large_blocks_of_data/


g-cont
> Тем не менее через полстраны коннект на 64 килобайта у меня стабильно устанавливается.
> Я проводил опрос, кол-во тех, у кого проходит 64к пакет к кол-ву тех, у кого не проходит
даже стало интересно в какой стране ты живёшь, что так можно запросто 64к через полстраны : )
и зачем проводить опрос, сервер не у тебя что-ли стоит?

Правка: 9 июня 2018 18:55

g-contПостоялецwww9 июня 201823:21#7
Delfigamer
> Длинную UDP-датаграмму проще выбросить, чем фрагментировать.
Ну это на усмотрение роутера, как я понимаю. Один выбросит, а другой сам начнёт фрагментировать. Гарантии никакой конечно.

Ghost2
> А reassembly проводи в софте
Да дело как бы в том, что если слать множество мелких пакетов, то это сильно дольше чем один но большой, я сравнивал. Там же ограничение на кол-во пакетов за еденицу времени.

Sh.Tac.
> хорошо бы гонять не пустые тестовые пакеты, а нагруженные полезными данными
Он не пустой в прямом смысле этого слова, там данные и для них считается CRC, чтобы убедиться что пакет прошёл в целости. Это просто тест для определения пропускной способности канала.

Sh.Tac.
> даже стало интересно в какой стране ты живёшь
Россия - страна чудес.

Sh.Tac.
> и зачем проводить опрос, сервер не у тебя что-ли стоит?
Необязательно у меня :)

g-contПостоялецwww9 июня 201823:24#8
ЗЫ. Насчёт органичения на кол-во пакетов за едницу времени. Может я конечно документацию читал невнимательно или чего-то не понял, но смысл таков - за один раз можно послать пачку из 32-х пакетов с размером MTU (~1436 байт). Затем сокет впадает в ступор и ему надо отдохнуть 1 милисекунду, после чего можно продолжать отправку. При таком раскладе скорость обмена данными падает почти вдвое.
Sh.Tac.Постоялецwww10 июня 20180:17#9
g-cont
> отдохнуть 1 милисекунду, после чего можно продолжать отправку. При таком
> раскладе скорость обмена данными падает почти вдвое
вдвое не может т.к. пинг >> 1 милисекунды
но в целом ограничение есть, если Ethernet 100 Mbps, то в одну миллисекунду должно быть вдвое больше чем в твоём примере
g-contПостоялецwww10 июня 201810:44#10
Sh.Tac.
я по всякому пробовал, наилучший результат достигается при отправке нефрагментированного пакета ~64к. Кстати такой вопрос, а могут ли быть разрешены большие пакеты из-за того что на роутере стрим TV?
ZabПостоялецwww10 июня 201812:10#11
g-cont
Для звуков и видео большие пакеты не используются. Это не выгодно.
Если не дошел один фрагмент - значит не дошло ничего, все остальное тоже выбрасывается. Если можешь порезать данные сам, исходя из задач, будет значительно лучше. UDP чаще всего используется в случаях, когда нам не важно дошло ли все, мы умеет работать в условиях неполных данных. К звуку и видео это тоже относится.

/ Форум / Программирование игр / Сеть

2001—2018 © GameDev.ru — Разработка игр