LWIP прием длинных пакетов Опции

[viakon]

LWIP фрагментированные пакеты собирает только если используется операционка? Использую standalone режим из примеров, при передаче пакета 2059 приходят два 1460 и 599. Как их правильно собрать в один? В инете пугают что они могут придти наборот вначале 599 байт.

STM32F107, LWIP 1.4.1, соединение TCP/IP.

Сообщение отредактировал viakon - Aug 10 2015, 05:22

[alx2]

при передаче пакета 2059 приходят два 1460 и 599.

соединение TCP/IP.

А разве в вашем пакете не установлен флаг "Don't fragment"?
Вообще-то при использовании TCP пакетам запрещают фрагментирование, и, если где-то в пути пакет превысил MTU, обратно отправляется icmp fragmentation needed...

[kolobok0]

..при использовании TCP пакетам запрещают фрагментирование...

1) говоря о TCP не корректно говорить о пакетах. это ПОТОКОВЫЙ протокол..
2) Если Вы имеете ввиду IP пакеты, то выставление флага фрагментации не зависит от уровня более верхнего протокола.

LWIP фрагментированные пакеты...при передаче пакета 2059 приходят два 1460 и 599....они могут придти наборот вначале 599 байт....соединение TCP/IP.

у Вас полная каша.
1) как уже прозвучало выше TCP потоковый протокол, там ФИЗИЧЕСКИ НЕТ пакетов. Когда ведут разговор про TCP протокол, то подразумевают
именно то что декларировано RFC. Если ведёте речь о более низких протоколах стэка - то так и пишите IP, EthFrame
2) TCP ГАРАНТИРУЕТ последовательную передачу потока данных. Т.е. всевозможные "наоборот", для данного потока - враньё по определению.


при работе с данным протоколом Вы можете запихать на передатчике 1460+599 и получить 10+300+1740+9, а можете получить сразу 2059
одним присестом - в зависимости от многих условий... Но данные ГАРАНТИРОВАННО придут именно в той последовательности в которой
были переданы...

[alx2]

1) говоря о TCP не корректно говорить о пакетах. это ПОТОКОВЫЙ протокол..

Хорошо. А через какой транспорт передается этот поток? У автора написано "TCP/IP". Говоря об IP корректно говорить о пакетах?

2) Если Вы имеете ввиду IP пакеты, то выставление флага фрагментации не зависит от уровня более верхнего протокола.

То есть Вы считаете нормальным, когда IP пакет, несущий данные TCP, не имеет флага Don't fragment?
По-моему это ненормально, о чем я и написал viakon.

[scifi]

Хорошо. А через какой транспорт передается этот поток? У автора написано "TCP/IP". Говоря об IP корректно говорить о пакетах?

Вы, наверное, не в курсе, что такое TCP/IP. Почитайте тут.
Это набор разных протоколов, многие из которых не имеют отношения к TCP, например ARP, ICMP, UDP.
Короче, TCP/IP - это слишком общий термин. Мы догадываемся, что автор имел в виду TCP, но вдруг ошибаемся?

То есть Вы считаете нормальным, когда IP пакет, несущий данные TCP, не имеет флага Don't fragment?
По-моему это ненормально, о чем я и написал viakon.

Вот тут есть вполне чеканный ответ на этот вопрос.
Если в двух словах, то по-разному бывает.

[alx2]

Короче, TCP/IP - это слишком общий термин. Мы догадываемся, что автор имел в виду TCP, но вдруг ошибаемся?

Давайте не будем гадать, а попросим viakon уточнить, о каком именно пакете размером 2059 байт он говорил. Мне почему-то кажется, что это не ARP.

Если в двух словах, то по-разному бывает.

Вопрос не в том, как бывает. Я допускаю, что TCP без DF возможно. Но вот нормально ли это? По вашей ссылке описана ситуация, когда сначала кто-то ломает в сети PMTUD, а потом в результате этого приходится убирать DF. Но когда сломано PMTUD - это уже ненормально...

Когда-то много лет назад в какой-то фидошной эхе спорили на эту тему (фрагментация IP пакетов). Я не поленился и поставил на одном из интернет-маршрутизаторов счетчики. Как оказалось, в реальной жизни ни одного (из многих миллионов) пакета (чтобы не было вопросов и догадок - я имею в виду пакета IP с кодом 6 в поле protocol) без флага DF не встретилось (за исключением TCP RST, которые большими не бывают). Это я к тому, как бывает в реальной жизни...

Поэтому, повторю, если у viakon пакет с данными передается без флага DF, ему, как минимум, надо обратить на это внимание и задуматься, почему так. Если, как в примере по ссылке, у него PMTUD сломано, так наверное лучше починить сломанное, чем бороться со следствиями...

[scifi]

Давайте не будем гадать, а попросим viakon уточнить

Он, похоже, потерял интерес к этой теме
Это всё интересно, конечно, про фрагментацию IP пакетов. Но мне-то кажется, что он просто ожидал отправить по TCP пачку данных размером около 2 КБ и принять такую же пачку на другой стороне. А оказалось, что lwip разбил эту пачку на кусочки (потому что сильно сомневаюсь, что MSS больше 2 КБ). Я просто обратил его внимание, что в режиме raw API по-другому и не будет, вот и всё. И фрагментация на уровне IP здесь ни при чём.

[viakon]

Он, похоже, потерял интерес к этой теме
Это всё интересно, конечно, про фрагментацию IP пакетов. Но мне-то кажется, что он просто ожидал отправить по TCP пачку данных размером около 2 КБ и принять такую же пачку на другой стороне. А оказалось, что lwip разбил эту пачку на кусочки (потому что сильно сомневаюсь, что MSS больше 2 КБ). Я просто обратил его внимание, что в режиме raw API по-другому и не будет, вот и всё. И фрагментация на уровне IP здесь ни при чём.

Интерес не пропал, на данный момент я решил проблему уменьшением размера пакета до 1к, потому как времени на эксперименты уже не было.
Я думаю что все дело в том, что мне приходится пользоваться практически raw ip без участия операционки.
И тут прослеживается следующая логическая цепочка. На компе после содинения TCP послылаются в сокет данные 2059 байт, естественно они разбиваются на 2 пакета. Первый пакет длиной в 1460 полезных байт принимается мироконтроллером, вырабатывается прерывание и вызов LwIP_Pkt_Handle(), вызывает tcp_echoserver_recv (торопился, потому не стал даже переименовывать названия фнкций в примере), где я и получаю эти 1460 байт. Думаю что если подождать с обработкой LwIP_Pkt_Handle() то после прихода второго пакета я получу свои данные но все равно с разбивкой на 2 части в структуре pbuf.
FreeRTOS не хочу использовать мало ОЗУ. А ради эксперимента прикручивать FreeRTOS лениво.

Сообщение отредактировал viakon - Aug 17 2015, 06:33

[scifi]

Думаю что если подождать с обработкой LwIP_Pkt_Handle() то после прихода второго пакета я получу свои данные но все равно с разбивкой на 2 части в структуре pbuf.

Именно так оно и работает.
И ещё раз повторяю: нужно быть готовым к тому, что эти 2 килобайта придут в виде 2048 пакетов по 1 байту каждый. Экзотика, да, но вполне законно. В этом случае просто подождать не получится - память закончится. Поэтому нужно в отдельном буфере накапливать данные по мере их поступления, не откладывая. И освобождать ненужные буферы сразу.

[viakon]

Именно так оно и работает.
И ещё раз повторяю: нужно быть готовым к тому, что эти 2 килобайта придут в виде 2048 пакетов по 1 байту каждый. Экзотика, да, но вполне законно. В этом случае просто подождать не получится - память закончится. Поэтому нужно в отдельном буфере накапливать данные по мере их поступления, не откладывая. И освобождать ненужные буферы сразу.

Как понять что пакет уже весь дошел?

[scifi]

Как понять что пакет уже весь дошел?

Это уже должен протокол поверх TCP разбираться. Например, в HTTP есть заголовок Content-Length. Скажем, если написано "Content-Length: 2048", то браузер знает, что в ресурсе ровно 2048 байт. Когда все байты пришли - всё готово.
Так что вам виднее, как оно у вас должно работать.