UDP размер сообщения

>Я имею ввиду что рассчитывая например на то, что сеть пропустит 20 кб в пакете можно наткнуться что данные вообще передаваться не будут никогда.

оно обернётся джамбой

Что это значит?

http://ru.wikipedia.org/wiki/Jumbo-%D0%BA%D0%B0%D0%B4%D1%80

Все равно нужна поддержка железки, и я так понял не все это поддерживают. Хотелось бы узнать какой-нибудь thump-rule максимальный размер пакета, чтобы ожидать что он дойдет в болшинстве случаев. А если не дойдет, то по причине сбоя, а не конфигурации железа

максмальный обычно 1500

а вообще кастуй nnz

Где ты начитался этих ужасов? Насколько я понимаю, UDP - это практически сырой IP, а датаграмма IP может быть до 64k, и он сам ее фрагментирует до MTU. Так что можно смело посылать UDP-сообщения до 64k-размер_IP-заголовка.

Это MTU на уровне IP. Если говорить о нем, то часто и того меньше. UDP умеет дробиться на такие пакеты. Вот только в идеальном мире он бы и 1 MB раздробил. Но у него ограничение по стандарту 64 КБ кажись, а на практике хрен знает сколько, оказывается как в голову стукнет разрабам железа

Было такое, сейчас форумы не скину. Но там например в BSD есть опция устанавливающая максимум. Выше чем надо она игнорит. И по дефолту значение невменяемое. Хотя я сам не тестил, это у ребят там на форуме было около 9 КБ или что-то такое.

/* Как правило, не превышают 9000 байт, поскольку в сетях Ethernet используется 32-битная CRC, которая теряет свою эффективность при объеме данных больше 12000 */

я только одного не могу понять что ты хочешь сделать

Не раздробил бы он 1 Мегабайт, там завязка на 16 байт (смещение/длина сейчас не вспомню). 64 килобайт по стандарту, а на практике, лучше завязывать свой протокол на MTU. Я про то, что ведь по хорошему, для гарантированной доставки должно быть предварительное согласование и т.д.

В общем случае для UDP-based протоколов фрагментирование лучше избегать. Стратегии разные: слать датаграммы с запрещенной фрагментацией (setsockopt(), IP_MTU_DISCOVER), уменьшая размер пакета, пока не пролезет. Также, если уже есть установленное TCP соединение, можно получить текущее, определенное ядром, значение MTU (getsockopt(), IP_MTU). В первом случае можно, например, использовать следующие значения (кусок кода из libjingle):

// Standard MTUs
const uint16 PACKET_MAXIMUMS[] = {
  65535,    // Theoretical maximum, Hyperchannel
  32000,    // Nothing
  17914,    // 16Mb IBM Token Ring
  8166,   // IEEE 802.4
  //4464,   // IEEE 802.5 (4Mb max)
  4352,   // FDDI
  //2048,   // Wideband Network
  2002,   // IEEE 802.5 (4Mb recommended)
  //1536,   // Expermental Ethernet Networks
  //1500,   // Ethernet, Point-to-Point (default)
  1492,   // IEEE 802.3
  1006,   // SLIP, ARPANET
  //576,    // X.25 Networks
  //544,    // DEC IP Portal
  //512,    // NETBIOS
  508,    // IEEE 802/Source-Rt Bridge, ARCNET
  296,    // Point-to-Point (low delay)
  //68,     // Official minimum
  0,      // End of list marker
};

В общем случае для UDP-based протоколов фрагментирование лучше избегать

А зачем если оно предусмотрено и включено по дефолту? Меньше 1500 это маловато как-то

> А зачем если оно предусмотрено и включено по дефолту? Меньше 1500 это маловато как-то

Ты хоть сформулируй задачу, которую решаешь.

> А зачем

Если какой-то роутер (а их будет несколько) на пути следования пакета фрагментирует/собирает обратно все пакеты, имеющие размер больше 2k, то мне кажется очевидным, что если слать пакеты <= 2k ты получишь более быструю передачу данных. Вообще, если возникают подобные вопросы, то это, пожалуй, верный признак того, что нужно использовать TCP и не париться.

Если какой-то роутер (а их будет несколько) на пути следования пакета фрагментирует/собирает обратно все пакеты, имеющие размер больше 2k, то мне кажется очевидным, что если слать пакеты <= 2k ты получишь более быструю передачу данных. Вообще, если возникают подобные вопросы, то это, пожалуй, верный признак того, что нужно использовать TCP и не париться.

ни один маршрутизатор по пути следования пакета не будет заниматься такой фигнёй.

> ни один маршрутизатор по пути следования пакета не будет заниматься такой фигнёй

Если мы здесь говорим об IPv4 и интернете в частности, то у меня для тебя плохие новости

Сейчас вроде все конечные устройства выставляют бит df, так что фрагментировать никто ничего не будет.

Значит это еще один довод в пользу того, что для UDP-based протоколов нужно проводить MTU discovery. Кстати, поделись пруфом про это твое «вроде».

Я же написал вроде? какие доказательства могут быть у предположения?

http://www.faqs.org/rfcs/rfc1191.html

Пункт 3.

Ну мало ли может ты какое исследование или рекомендации производителям оборудования в предверии перехода на IPv6 читал. Просто интересно стало. RFC 1191 и пункт 3 в частности к твоему первоначальному посту отношения особого не имеют.