[viakon 0]

Именно так оно и работает.

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

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

[scifi 1]

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

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

Так что вам виднее, как оно у вас должно работать.

[dmitry-tomsk 0]

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

Так что вам виднее, как оно у вас должно работать.

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

[kolobok0 0]

...Говоря об IP корректно говорить о пакетах? ...нормальным, когда IP пакет, ...не имеет флага Don't fragment?....

 

ниже TCP естественно используется IP (см. стэк). И естественно на уровне IP есть понятие пакетов, есть и сборка пакетов,

есть и флаг не дефрагментировать.

Но ТС говорит: пакеты при использование LWIP соединение TCP. Т.е. речь идёт именно об использовании а не реализации или как работать

с пакетами IP чтоб получить поток в TCP. Т.е. ТС явно мыслит на уровне использования стэка TCP.

 

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

для гражданского использования) вполне может стоять, а может и не стоять. Это не есть обязательное условие при использовании

какого-либо протокола, в том числе и TCP.

 

...прослеживается следующая логическая цепочка. На компе после содинения TCP послылаются в сокет данные 2059 байт, естественно они разбиваются на 2 пакета. Первый пакет..

 

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

Вы сильно удивитесь увидев другой результат :)

 

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

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

нет никаких проблем...

 

 

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

 

Если используете TCP уровень - там нет пакетов. Ну нет...физически...

В силу реализации софта, и ситуации в канале связи на данный момент времени - результат по группировки пересылаемых данных

не определён. TCP гарантирует последовательную доставку данных... Т.е. выпихнули - обязательно получите...

выпихнули 100+20+30+555+1

получите (в той же самой последовательности) 222+1+483

 

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

хоть передачей в заголовка самой длины данных, хоть ..... как угодно...

 

[Hold 0]

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

Как именно стоит использовать поле tot_len?

У себя делал следующим образом:

1. Принимаю пакет netconn_recv(conn, &inbuf);

2. Определял длину пакета buflen = netbuf_len(inbuf);

3. Выделял память DataPtr = pvPortMalloc(buflen);

4. И копировал туда весь буфер netbuf_copy(inbuf,DataPtr,buflen);

Вопрос вот в чем: отправляю файл 200 кбайт, по логам вижу как прилетают пакеты:

192.168.10.21:60293 data len:1460
192.168.10.21:60293 data len:20
192.168.10.21:60293 data len:1460
192.168.10.21:60293 data len:60
192.168.10.21:60293 data len:1460
192.168.10.21:60293 data len:20
192.168.10.21:60293 data len:1460
192.168.10.21:60293 data len:40
192.168.10.21:60293 data len:1460
192.168.10.21:60293 data len:20
192.168.10.21:60293 data len:760
192.168.10.21:60293 data len:45

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

[Сергей Борщ 119]

Как понять что я все принял? Вводить таймаут, городить свой протокол поверх?

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

 

[viakon 0]

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

 

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

Изменено 28 января, 2017 пользователем viakon

[zltigo 0]

Если работаете с TCP - то это потоковый протокол

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

[Сергей Борщ 119]

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

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

 

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

Basic Data Transfer:

 

The TCP is able to transfer a continuous stream of octets in each

direction between its users by packaging some number of octets into

segments for transmission through the internet system. In general,

the TCPs decide when to block and forward data at their own

convenience.

 

 

[zltigo 0]

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

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

Протокол вне зависимости от режима сокета чисто пакетный - оформление фрейма, размер... Поверх TCP, да уже действительно потоковые протоколы в прямом понимании этого слова, навешиваются.