Если я использую сырые сокеты для отправки пакета UDP размером 3000 байт, нужно ли мне самому обрабатывать фрагментацию пакетов в коде, или если фрагмент фрагмента raw-дескриптора похож на сокет DGRAM?фрагментация пакетов для сырых сокетов
Ну, если вы используете UDP, вы на самом деле не отправляете RAW. RAW вообще не будет IP, и в таком случае да вам придется обрабатывать фрагментацию самостоятельно.
С UDP вы получаете поддержку фрагментации IP, что является ИМХО достаточно хорошим для сетей с малой дальностью, где столкновения должны быть минимальными. Сделайте связь между двумя системами выделенной подсети, и это не проблема.
Что TCP покупает вас через UDP (между прочим) - это способность стека просто переслать один фрагмент, если он каким-то образом потерялся или получил доступ. С UDP, если это происходит, все сообщение должно быть отброшено. Там есть накладные расходы, и для большинства современных сетей вы, вероятно, можете жить с этим компромиссом.
Согласитесь с точкой в отношении других ответов, не хватает «rawness». Не согласитесь с вашим заключением, хотя в некоторых системах есть сокеты «raw IP», где вы все еще указываете адрес источника и адрес назначения IP-заголовка, но сами пишите остальную часть пакета. В этом случае будет IP-заголовок (половина построена приложением и половина управляется нижним уровнем), и он будет иметь бит DF как обычно. – Flexo
@awoodland - Интересно. Мой опыт в основном заключается в написании собственных стеков. Если пользователь обрабатывает заполнение IP-пакета, я думаю, что им также придется обрабатывать сборку входящих IP-фрагментов в сообщения. –
Я думал, что вопрос был о передаче только с тех пор, как он спросил о отправке!Проблема в том, что на самом деле не совсем понятно, что подразумевается под «сырым» в этом случае. – Flexo
Нет, фрагментация пакетов обрабатывается на более низком уровне. Вы должны увидеть, что именно вы положили в пакет. То есть UDP гарантирует границы сообщений.
Базовый протокол IP продолжает обрабатывать фрагментацию. Думаю, пока вы не устанавливаете бит DF (не фрагментируйте), все должно быть хорошо.
В зависимости от вашей системы это можно обрабатывать совершенно по-другому. Например, в Linux вы можете попросить нижние уровни обработать обнаружение MTU пути и дать ошибку (EMSGSIZE), если вы попытаетесь отправить что-то большее, чем (известный) путь MTU.
Как «сырой» это сырой сокет, о котором вы говорите? Другие системы могут просто позволить вам управлять битом DF (или вы можете сами создавать большую часть заголовка IP), и в этом случае поведение также будет зависеть от этого.
Как правило, если вы передаете с помощью DF-набора, вы, как правило, получаете возможность увидеть ошибку в пользовательском пространстве или иметь более низкие уровни на открытии PMTU вашего хоста и останавливать отправку чего-то слишком большого. Если вы не установите DF, тогда вы (вероятно) увидите соответствующую фрагментацию от маршрутизатора (ов) по пути.
Если я не ошибаюсь, и я сомневаюсь, что я с этим, вам нужно беспокоиться о потерянных пакетах и т. Д., UDP - это протокол лучших усилий. – thecoshman
Пакеты (если recv'd) в порядке - заказ, однако, не гарантируется. Очевидно, что если вы отправляете/resp/send/resp, это не проблема, но будет, если вы потоки. Проблема с UDP заключается в том, что после того, как вы внедрили всю домашнюю работу, вы просто хотите, чтобы вы сделали TCP в первую очередь. Как правило, это не тот случай, когда вас не интересуют пропущенные пакеты. – KevinDTimm
Можете ли вы уточнить, что именно вы подразумеваете под сырым в этом случае? Вы пишете необработанные пакеты Ethernet, необработанные IP-пакеты? В какой системе вы это делаете? Некоторые системы дают какой-то «пол-n-й» сокет ... – Flexo