Датаграмма UDP может прийти в неверном порядке. Как это?

Question

[Fjfgs]

То есть я могу отправить:
012345
А получить:
253401

Если да, то эту проблему решают только через CRC32 или подобные ему алгоритмы путем проверки целостности датаграммы и последующей переотправки?

Comments

[Akina]

Если речь об ОДНОЙ датаграмме из 6 символов - то такое вряд ли возможно.

Answer 1

[hint000]

То есть я могу отправить:
012345
А получить:
253401

Во-первых, если важно получить 012345, то надо посылать в одной датаграмме 012345, а не в шести отдельно по одному символу.
Во-вторых, даже если отправлять по одному символу, то вероятность получить 253401 очень мала.
Скорее вы можете получить 02345 или 01345 или 135, т.е. простую потерю пакетов. Неверный порядок возможен, но в реальной жизни будет редко встречаться (он может быть вызван повторной отправкой кадров, т.е. проблемами на более низком уровне OSI, тогда первая датаграмма может задержаться из-за переотправки кадров, из которых она состоит, а вторая датаграмма может пройти без ошибок в кадрах и оказаться у получателя раньше первой; а ещё они могут пойти разными маршрутами с разной задержкой, но это уже экзотика).

Comments

[Fjfgs]

То есть не надо превышать MTU, ведь если нет фрагматации, то нет непрвильного порядка?(правильно ли я понял)

[hint000]

Fjfgs, нет, неправильно. Датаграмма - это пакет. Даже если пакет будет фрагментирован, его фрагменты невозможно собрать неправильно. Либо он соберётся правильно, либо совсем не соберётся и будет считаться потерянным.
Фрагментация никогда не изменит порядок датаграмм.

То есть не надо превышать MTU

MTU не надо превышать по другой причине: фрагментация часто бывает запрещена где-то по маршруту, и тогда большие пакеты просто не доходят.

Answer 2

[pfg21]

такое невозможно, внутри пакета UDP последовательность данных изменится не может.
датаграмма UDP упаковывается в пакет IP, который может фрагментироваться.
перед передачей данных в драйвер UDP, драйвер IP восстановит правильную последовательность данных, либо дропнет весь пакет, если все фрагменты не придут в течении тайм-аута.
для прямого запрета фрагментации пакета IP нужно устанавливать флаг DF (don't fragment) в пакете IP.

а в случае когда 012 и 345 посланы в разных пакетах UDP вполне. восстановление последовательности пакетов в UDP нет и последний по отправке пакет может прийти раньше первого посланного.

Answer 3

[asmelnik]

Датаграмма UDP может прийти в неверном порядке. Как это?

Данные "внутри" одной датаграммы -- нет, не могут прийти в произвольном порядке.
Если ваш вопрос переформулировать как

ДатаграммЫ UDP моГУТ прийти в неверном порядке. Как это?

То да, могут.
Отправив датаграммы с номерами 0,1,2,3,4
Вы на принимающей стороне их можете получить в произвольном порядке. Это заложено в самом IP и НИКАК не исправляется средствами IP или UDP.
Только протоколом более высокого уровня "внутри" UDP и то на стороне приемника в процессе обработки всей серии.

Answer 4

[nApoBo3]

Такие проблемы не решают за исключением специальных случаев когда применение tcp по каким-то причинам невозможно.

Comments

[Fjfgs]

Спасибо за ответ, но у меня специфический случай)

[nApoBo3]

Fjfgs, тогда вам нужно фактически писать свою реализацию tcp поверх udp. В tcp контроль последовательности прихода пакетов производится без контрольных сумм.

[Fjfgs]

nApoBo3, да. Я пишу rudp.

[nApoBo3]

Fjfgs, тогда вам сначала следует изучить tcp, решить чём именно он вас не устраивает и реализовать все остальное руками.
Чек суммы для описанной вами задачи подходят не очень, поскольку их овержед будет вероятно выше, чем использование tcp.
Чек сумма "гарантирует"( на самом деле нет, но это выходит за рамки дискуссии ) целостность данных внутри пакета. Если вы применяет чек суммы к пакетам которые формируете в слое который написали поверх udp, то для этого слоя пакет неделим. Если ваш слой упаковывает ваш пакет в один udp пакет без фрагментации, то вы просто добавили ещё одну чек сумму которая в udp и так есть, если упаковка происходит с фрагментацией, то потеря любого udp фрагмента приведет к необходимости отправки всех udp фрагментов повторно, что может быть очень накладно, а главное требует "таймаута" по каждому из пакетов, т.е. вы начнёте повторную отправку не тогда когда не пришел скажем второй или первый сегмент, а когда мы "получили" все сегменты и не смогли их собрать. При этом мы могли получить их все, но не в том порядке, и их все равно нужно будет все отправить повторно.
Для контроля последовательности пакетов в tcp используется последовательный "номер" пакета.