[dimka76 42]

Продолжу, пожалуй, эту тему, чтобы не создавать новую, т.к. вопрос близкий к теме.

При получении данных по TCP из интернета эти данные иногда приходят в произвольном порядке. Т.е. sequnce number очередного пакета не соответствует

sequnce number предыдущего пакета с учетом количества переданных данных.

SN(i) > SN(i-1) + LEN(i-1) - как то так.

На картинке ниже это выглядит следующим образом

При этом стек LwIP полностью подтверждает все приняты данные. 

Но тот пакет, который пришел не по порядку, не приводит к вызову коллбэк функции.

В итоге, все пакеты подтверждены, но часть данных потеряна в недрах LwIP.

Что делать ?

[dimka76 42]

Попробую напомнить о своем вопросе 

[Arlleex 131]

В 08.05.2023 в 20:11, dimka76 сказал:

Но тот пакет, который пришел не по порядку, не приводит к вызову коллбэк функции.

Какой функции?

Цитата

В итоге, все пакеты подтверждены, но часть данных потеряна в недрах LwIP.

Какая часть данных потеряна? Сколько буферов PBUF (или как они там в LwIP зовутся) выделено для TCP-сокета в настройках стека? Каков размер окна там же?

[dimka76 42]

On 5/16/2023 at 8:34 AM, Arlleex said:

Какой функции?

В LwIP есть функции, которые вызываются при приеме пакета по TCP

 

On 5/16/2023 at 8:34 AM, Arlleex said:

Какая часть данных потеряна? 

Теряется та часть данных, которая передавалась в пакете, пришедшем не по порядку. На приведенной выше картинке - порядка 500 байт, при размере MSS 1200 байт

On 5/16/2023 at 8:34 AM, Arlleex said:

Сколько буферов PBUF (или как они там в LwIP зовутся) выделено для TCP-сокета в настройках стека? Каков размер окна там же?

Количество буферов пробовал и 4 и 8.

MSS = 1200

WIN = 4*MSS

[jcxz 187]

В 08.05.2023 в 20:11, dimka76 сказал:

Но тот пакет, который пришел не по порядку, не приводит к вызову коллбэк функции.

Если я правильно понял - так это и логично вроде как. Так как TCP должен восстанавливать порядок байт. А значит должен сообщить пользователю о приёме данных, только когда принята и собрана вся последовательность от последнего сквитированного октета.

А как иначе ему восстанавливать порядок байт в потоке?

3 часа назад, dimka76 сказал:

В LwIP есть функции, которые вызываются при приеме пакета по TCP

По идее должны вызываться не при приёме пакета (так как в TCP нет понятия "пакетов"), а при обновлении последней подтверждённой позиции принятых данных.

3 часа назад, dimka76 сказал:

Теряется та часть данных, которая передавалась в пакете, пришедшем не по порядку.

Именно теряется? Т.е. - её невозможно считать из буфера потока TCP?

[dimka76 42]

On 5/16/2023 at 12:51 PM, jcxz said:

Если я правильно понял - так это и логично вроде как. Так как TCP должен восстанавливать порядок байт. А значит должен сообщить пользователю о приёме данных, только когда принята и собрана вся последовательность от последнего сквитированного октета.

А как иначе ему восстанавливать порядок байт в потоке?

По идее должны вызываться не при приёме пакета (так как в TCP нет понятия "пакетов"), а при обновлении последней подтверждённой позиции принятых данных.

Именно теряется? Т.е. - её невозможно считать из буфера потока TCP?

Да, именно теряется.

Приложение ждет определенного количества данных и не дожидается.

Когда все пакеты по TCP идут по порядку, то приложение успешно дожидается нужного количества байт.

Да, еще уточнение. На компе две сетевых карты: одна с выходом в инет, а к другой подключено мое устройство. Компьютер таким образом является посредником между интернетом и моим устройством.

Может это как раз компьютер и перемешивает пакеты ?

[jcxz 187]

10 минут назад, dimka76 сказал:

Когда все пакеты по TCP идут по порядку, то приложение успешно дожидается нужного количества байт.

Вас трудно понять - о каких "пакетах по TCP" всё время говорите?? 

TCP отдаёт пользователю поток байт (октетов). В котором нет никаких "пакетов".

В нижележащих (ниже TCP) протоколах есть "пакеты". Но перемешивание их не должно никак сказываться на корректности работы TCP.

[jcxz 187]

По логу обмена из 1-го поста видно, что в строчке 71 TLS-клиент подтвердил все 4097 байт отправленных перед этим TLS-сервером. А значит он все их получил. Без каких либо потерь. А то что в строках 63...67 есть повторы некоторых данных и перемешан порядок логгирования их, то - какая разница? если все данные ваш стек подтвердил (т.е. - получил)

Криминала не вижу.

[dimka76 42]

On 5/16/2023 at 1:47 PM, jcxz said:

По логу обмена из 1-го поста видно, что в строчке 71 TLS-клиент подтвердил все 4097 байт отправленных перед этим TLS-сервером. А значит он все их получил. Без каких либо потерь. А то что в строках 63...67 есть повторы некоторых данных и перемешан порядок логгирования их, то - какая разница? если все данные ваш стек подтвердил (т.е. - получил)

Криминала не вижу.

Да, я это все наблюдал и понимаю. И поэтому с своем первом сообщении, в том к которому прикрепил картинку, и написал, что теряется в недрах LwIP.

Потому что на следующий уровень, на вход TLS, то количество принятых байт, которое мы видим в строчке 66, не передается.

[jcxz 187]

17 минут назад, dimka76 сказал:

Потому что на следующий уровень, на вход TLS, то количество принятых байт, которое мы видим в строчке 66, не передается.

Возможно есть какая-то проблема между TLS и TCP. Не имел дел с LwIP (в открытом виде), но я бы посмотрел например на размер буфера TCP-сокета. Так как TLS должен читать данные из него. Его в LwIP можно конфигурить? Может его размер маловат для работы TLS? Поставьте (если возможно) его хотя бы >= 5КБ.

PS: Кстати - размер окна у вас пишете = 4800? Размер буфера TCP-сокета равен размеру окна?

[dimka76 42]

On 5/16/2023 at 2:25 PM, jcxz said:

Возможно есть какая-то проблема между TLS и TCP. Не имел дел с LwIP (в открытом виде), но я бы посмотрел например на размер буфера TCP-сокета. Так как TLS должен читать данные из него. Его в LwIP можно конфигурить? Может его размер маловат для работы TLS? Поставьте (если возможно) его хотя бы >= 5КБ.

PS: Кстати - размер окна у вас пишете = 4800? Размер буфера TCP-сокета равен размеру окна?

В LwIP есть такая опция

/**
 * TCP_QUEUE_OOSEQ==1: TCP will queue segments that arrive out of order.
 * Define to 0 if your device is low on memory.
 */

Надо посмотреть включена ли она у меня.

[dimka76 42]

On 5/16/2023 at 2:25 PM, jcxz said:

Размер буфера TCP-сокета равен размеру окна?

Я не так глубоко знаком с LwIP 

Там все как-то хитро макросами вычисляется.

[dimka76 42]

Разобрался я.

Я не правильно забирал данные в той самой callback функции.

Т.е. вычитывал их не полностью. Стек LwIP передает цепочку буферов, а я вычитывал только данные из первого буфера этой цепочки.

Но сообщал стеку, что как-будто вычитал все. Поэтому стек подтверждал отправителю все данные, а у меня данных не хватало.

 

[Arlleex 131]

11 часов назад, dimka76 сказал:

Т.е. вычитывал их не полностью. Стек LwIP передает цепочку буферов, а я вычитывал только данные из первого буфера этой цепочки.

Да, у них там весьма витиеватая система буферизации. Вы же даже исходник свой не приводили))

Кстати, Вы используете не NetConn-ы, а, видимо, Raw API. Почему?

[dimka76 42]

On 5/17/2023 at 8:34 AM, Arlleex said:

Кстати, Вы используете не NetConn-ы, а, видимо, Raw API. Почему?

Так повелось )))

Я с RAW API более-менее разобрался. Да и то не до конца, раз еще спотыкаюсь.

On 5/17/2023 at 8:34 AM, Arlleex said:

Вы же даже исходник свой не приводили))

Я изначально думал, что вопрос принципиальный. А оказалось, что дело в моем коде было.

On 5/17/2023 at 8:34 AM, Arlleex said:

Кстати, Вы используете не NetConn-ы, а, видимо, Raw API. Почему?

А чем netcon лучше ?