Всем добрый день.

Возник вопрос по разделению различных соединений TCP в LwIP.
Открываю первое соединение. В обработчике ...accept
получаю некий pcb (смотрю ссылку - она 536898084 (преобразование ссылки в число)).
Далее не закрывая предыдущее соединение открываю второе с того же IP
и к тому же порту! Это важно.
В ...accept получаю ссылку уже на другой pcb (536897788)
Все нормально.
Но далее замечаю, что данные поступают с обоих соединений на ОДИН из 2-х существующих pcb.
При открытии соединения с разных IP или на разные порты такой проблемы не возникает.

Вообще этот эффект (если я правильно его идентифицировал) вызывает
большие и непреодолимые проблемы при поддержке нескольких пользователей.
Допустим 2-й послал некую команду и закрыл соединение.
Закрылся первый pcb (для каждого уникального pcb я создаю уникальный контекст пользователя).
Это выгрузит контекст 1 из памяти и закроет 1-й pcb.
При этом пользователь 1 такую команду не подавал.
И кроме того контекст 2 и 2-й pcb не выгружены из памяти! Конечно они могут быть закрыты по таймеру, но это не решение вообще.

Ситуация, когда с одного IP и к одному порту создается несколько соединений абсолютно нормальна.
Это делают все браузеры для запросов разных объектов на странице (к порту 80).
Также (как пример) это может сделать Total Commander при открытии фоновой загрузки по FTP (к порту 21).
Поэтому ситуация абсолютно жизненная.

Этот вопрос в документации на LwIP не освещен абсолютно.
Кто что знает?

У меня сделан веб сервер на lwip. Браузер открывает по два соединения одновременно. Никаких проблем не возникает. Ищите косяк у себя.

У ВСЕХ WEB сервер сделанный на LwIP работает.
Но это вовсе не означает отсутствие этой проблемы.
Поскольку браузер посылает один запрос HTTP при открытии соединения.
Он сразу обрабатывается и файл ставиться на отправку.
Далее браузер уже ничего не передает серверу.
По окончании отправки соединение закрывает сервер.
В этой цепочке событий проблема не возникает.

А вот если клиент посылает команды с паузой и после получения данных
по тому же соединению (ответ на предыдущие команды FTP, к примеру) - проблема возникает.
Конечно я могу ошибаться. Естественно.
Но прежде чем задавать вопрос я отследил проблему и обоснованно задал вопрос.
Эксперимент проводил просто и наглядно.
Открываю 2 копии гипертерминала на одной машине к серверу к некому порту (21-му)
Сервер вываливает ссылки на pcb и принятые данные через USART на обычный ком порт.
Ну и вижу сами данные и на какую копию pcb они сваливаются.

Специально сделал захват пакетов. Посмотрите, там оч. хорошо видно, что идёт одновременная передача данных по разным соединениям.

Вооот!!!

Вы так и не поняли проблему.
Я таких логов насмотрелся вдоволь - тут все ОК.
Я же не пишу что не передается по разным TCP соединениям!
Я описываю ситуацию, когда ПРИНИМАЕТСЯ на неправильный pcb (в ethereal этого не видно!!)
Это видно только ВНУТРИ контроллера.
И возникает это не всегда.
А только после отправки пакета TCP из LwIP и только после этого приход пакета извне
по тому же TCP коннекту вызывает заморочку. Чего не видно в данном логе!
И пакет этот должен быть с данными (не голый ACK)

Впрочем Вы навели на мысль вываливать в лог не только ссылку на pcb,
но и полную расшифровку IP+порты, взятую из текущего pcb
Это может прояснить ситуацию.
Не исключено, что инфа о TCP варьируется в одной копии pcb в зависимости
от принятого пакета (хотя это бредово) и стоит ориентироваться не на pcb и соответственно
конкретный свалившийся в обработчик arg, а на что то иное.

Внутри lwip код довольно нехитрый:

Нет причин ждать там подвоха. И, я думаю, такой косяк народ давно уже заметил бы и исправил.
Возможно, у вас память портится или что-то в этом духе. Недостаточный размер стека и всё такое. Всякое бывает.

Хм. Спасибо за кусок кода - я его не искал, хотя и подозревал, что он должен быть таким (а что может быть иное...)
Правда это не исключает проблемы с содержимым любой из представленных переменных:D в силу некой скрытой проблемы.
Конечно о порче памяти и т.п. думал. Хотя ничего не виснет и других признаков проблем нет (софт выполняет и другие задачи).

Но в любом случае спасибо!

Я склоняюсь к мысли, что надо внимательно разглядывать входящий/исходящий порт соединения, может это наведет на корень проблемы.

У меня вообще были чудеса чудесные. Видимо, память утекала, пока он не отказывался отвечать на запросы (хотя пинг, по-моему, всё ещё работал). Поставил низший уровень оптимизации - отлегло. С тем компилятором я и до того глюки оптимизации видел (например MD5 считал неверно). Я снизил уровень оптимизации на средний, вроде бы всё заработало, а оказалось, что глюки полезли из других мест