-
- Просто сначала надо склеить фрагментированный IP, при условии что пакеты могут придти в любом порядке, затем пересчитать контрольную сумму. Ну и в обратную сторону то же, но, контрольная сумма в первом пакете, и последовательно - 1 пакет 2 пакет OlegPowerC(161 знак., 23.07.2012 17:48)
- для маленьких девайсов нормально ожидать следующий пакет и отбрасывать преждевременные - koyodza(23.07.2012 18:01)
- Да это понятно, я сейчас озадачен вот чем: Хочу сделать чтоб можно было установить MTU например 200 байт. И обрабатывать это все на уровне IP - OlegPowerC(23.07.2012 18:22)
- я Вас прекрасно понял
что Вы не Иванови именно об этом и говорю: ожидать только правильный по счету пакет, а если раньше придет более поздний, то его отбрасывать koyodza(73 знак., 23.07.2012 18:54)- Когда TCP - тогда фрагментация IP особо не нужна, а вот с UDP не получится по другому. Кстати в lwIP вроде фрагментация есть - OlegPowerC(23.07.2012 19:09)
- А почему не получится? Те же GSM-модемы с стеком TCP/IP не факт что фрагментацию поддерживают. - Apтём(23.07.2012 19:38)
- Зависит от приложения. Если приложение тупо шлет UDP пакеты рамером 65535 байт, то не получится. А если шлет пакеты размером 64-576 байта, то получится. :) - USSR(23.07.2012 19:48, )
- Такое тупое приложение может быть, согласен. А почему 576? Это ошибка, или для >576 уже нужна поддержка фрагментации? - Apтём(23.07.2012 19:56)
- Насчет 576 - есть RFC (не помню номер). В общем канал связи обязан прозрачно прожевывать IP пакеты до 576 байт размером. То есть IP header + TCP header + 512 байт данных обязаны пролезать без фрагментации. - LightElf(23.07.2012 20:38)
- RFC791: «All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is USSR(83 знак., 23.07.2012 21:44, )
- Да, такие датаграммы, хосты должны принимать, причем как одно целое так и нарезанные фрагментами - OlegPowerC(24.07.2012 12:06)
- RFC791: «All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is USSR(83 знак., 23.07.2012 21:44, )
- Поддержка фрагментации нужна в сетях где MTU меньше стандартного, или пакет уровнем выше IP, большой. Например VPN уже уменьшит MTU - OlegPowerC(23.07.2012 20:03)
- А понятно. Видимо с GSM такие случаи мне не попадались. - Apтём(23.07.2012 20:10)
- Насчет 576 - есть RFC (не помню номер). В общем канал связи обязан прозрачно прожевывать IP пакеты до 576 байт размером. То есть IP header + TCP header + 512 байт данных обязаны пролезать без фрагментации. - LightElf(23.07.2012 20:38)
- Такое тупое приложение может быть, согласен. А почему 576? Это ошибка, или для >576 уже нужна поддержка фрагментации? - Apтём(23.07.2012 19:56)
- Зависит от приложения. Если приложение тупо шлет UDP пакеты рамером 65535 байт, то не получится. А если шлет пакеты размером 64-576 байта, то получится. :) - USSR(23.07.2012 19:48, )
- А почему не получится? Те же GSM-модемы с стеком TCP/IP не факт что фрагментацию поддерживают. - Apтём(23.07.2012 19:38)
- Когда TCP - тогда фрагментация IP особо не нужна, а вот с UDP не получится по другому. Кстати в lwIP вроде фрагментация есть - OlegPowerC(23.07.2012 19:09)
- я Вас прекрасно понял
- Да это понятно, я сейчас озадачен вот чем: Хочу сделать чтоб можно было установить MTU например 200 байт. И обрабатывать это все на уровне IP - OlegPowerC(23.07.2012 18:22)
- для маленьких девайсов нормально ожидать следующий пакет и отбрасывать преждевременные - koyodza(23.07.2012 18:01)
- Просто сначала надо склеить фрагментированный IP, при условии что пакеты могут придти в любом порядке, затем пересчитать контрольную сумму. Ну и в обратную сторону то же, но, контрольная сумма в первом пакете, и последовательно - 1 пакет 2 пакет OlegPowerC(161 знак., 23.07.2012 17:48)