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

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

Делал LwIp на xilinx, на пакеты разбивает по 1460 байт, пакеты там связаны, нужно использовать поле tot_len pbuf. Удобно пользовать pbuf_copy_partial.

ниже TCP естественно используется IP (см. стэк). И естественно на уровне IP есть понятие пакетов, есть и сборка пакетов,
есть и флаг не дефрагментировать.
Но ТС говорит: пакеты при использование LWIP соединение TCP. Т.е. речь идёт именно об использовании а не реализации или как работать
с пакетами IP чтоб получить поток в TCP. Т.е. ТС явно мыслит на уровне использования стэка TCP.

по поводу флага. Он (и кстати другие флаги - например быстрой передачи или скажем признак спец флагов спецификация которых закрыта
для гражданского использования) вполне может стоять, а может и не стоять. Это не есть обязательное условие при использовании
какого-либо протокола, в том числе и TCP.



попробуйте перевёрнутым кроссом соединить два девайса напрямую и повторите эксперимент.
Вы сильно удивитесь увидев другой результат

Я Вам более скажу, что если будете посылать из под винды - будет один результат (без свитчей связь). Если будете посылать с девайса например -
будет другой результат(где отключите максимальную длину IP пакета, ну или измените её...) Вплоть до 65кил пакеты IP можно гнать - тут
нет никаких проблем...




Если используете TCP уровень - там нет пакетов. Ну нет...физически...
В силу реализации софта, и ситуации в канале связи на данный момент времени - результат по группировки пересылаемых данных
не определён. TCP гарантирует последовательную доставку данных... Т.е. выпихнули - обязательно получите...
выпихнули 100+20+30+555+1
получите (в той же самой последовательности) 222+1+483

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

Как именно стоит использовать поле tot_len?
У себя делал следующим образом:
1. Принимаю пакет netconn_recv(conn, &inbuf);
2. Определял длину пакета buflen = netbuf_len(inbuf);
3. Выделял память DataPtr = pvPortMalloc(buflen);
4. И копировал туда весь буфер netbuf_copy(inbuf,DataPtr,buflen);
Вопрос вот в чем: отправляю файл 200 кбайт, по логам вижу как прилетают пакеты:

Как понять что я все принял? Вводить таймаут, городить свой протокол поверх? Понимаю что это просто поток байт, но почему-то думал что возможно отследить что мы все получили

Если работаете с TCP - то это потоковый протокол, передача длины или признак конца данных осуществляется в протоколе более верхнего уровня.

Т.е нужно писать свою обвязку к протоколу IP. Или не использовать длинные пакеты.

Сообщение отредактировал viakon - Jan 28 2017, 15:04

TCP ни разу потоковый протокол. Он пакетный.

Сокет открывается с параметром SOCK_STREAM. "Совпадение? Не думаю!".

И как тогда перевести этот отрывак из RFC:

Да как угодно. Что было голове написавшего STREAM, как признак того, что для передаваемых ПАКЕТОВ, не гарантируется их нефрагментироание, мне неведомо. Для пакетов с гарантированным отсутствием фрагментации бывает поддержка SEQPACKET режима сокета.
Протокол вне зависимости от режима сокета чисто пакетный - оформление фрейма, размер... Поверх TCP, да уже действительно потоковые протоколы в прямом понимании этого слова, навешиваются.