[dimka76 64]

Насколько я знаю ACK должен отпраляться через 200 mS после приема одиночного пакета или после каждого второго пакета.

На Win 7 x64 столкнулся с тем, что комп иногда отправляет ACK не после каждого второго, а после первого сразу.

Вот поясняющая картинка строчка 1263 .

 

Что это баг или фича ?

 

Если у кого есть wireshark , то прикладываю сохраненый лог.

1_1263.rar

[Rst7 5]

Ну, видимо, такое поведение у стека в Win7. Собственно говоря, ничем это не грозит, если, конечно, в Вашем стеке все правильно работает.

[dimka76 64]

Спасибо.

 

[dimka76 64]

Дабы не плодить схожие темы продолжу здесь.

 

Если я отправил подряд два пакета по 1000 байт каждый и перед отправкой очередной порции жду подтверждения, отправленных мною 2000 байт, а мне приходит подтверждение только 1000 байт вместо 2000 байт, что я должен делать в этом случае ?

[krux 8]

а мне приходит подтверждение только 1000 байт вместо 2000 байт, что я должен делать в этом случае ?

по истечении таймаута на ACK, повторить передачу того пакета в 1000 байт, на который ACK не пришёл.

[dimka76 64]

Да, спасибо.

 

Вполне логично. Но у меня нет времени ждать.

Я думаю, что если не смотря на неподтвержтенные данные продолжать слать пакеты, то компьютер все равно рано или поздно все подтвердит.

 

[Rst7 5]

Но у меня нет времени ждать.

Я думаю, что если не смотря на неподтвержтенные данные продолжать слать пакеты, то компьютер все равно рано или поздно все подтвердит.

 

Естественно нет. Ибо неполученные пакеты не подтвердит. Их надо перепосылать, на что в простейшем случае тратится время. Однако рекомендую почитать про Fast Retransmit.

[krux 8]

в заголовке TCP пакета есть sequence number и на стороне приема TCP-стек производит reassembly перед тем, как отдать данные в пользовательское приложение. т.е. приложение не получит данные пока не придет "пропавший" пакет. Сделано это для того чтобы пользовательское приложение получило данные по порядку, вне зависимости от того в каком порядке они были переданы по сети. Более того, если этот пакет не придет, то в зависимости от реализации TCP-стека он может решить разорвать соединение.

[dimka76 64]

Да нет.

В моем случае пакеты не теряются. Просто (см. первое сообщение топика) в строке 1264 комп отправляет "внеплановый" ACK. А мое устройство его реально получает ( иобрабатыват) только тогда, когда отправило пакет в строке 1265. И ожидает АСК пакета 1265, а на самом деле получает АСК пакета 1263.

 

И вот я думаю как правильнее сделать реакцию на такую ситуацию в стеке ТСР.

[krux 8]

обычно хранят как сами отправляемые пакеты, так и их список в виде linked-list. Вновьотправленные пакеты добавляются в конец списка.

По приходу ACK на пакет, его SeqNum ищется в списке - если он есть то освобождается память занятая под пакет, и удаляется запись из списка.

При этом периодически в списке обновляется время относительно момента отправки (условно - TTL). Если значение превысило таймаут - пакет перепосылается.

[Rst7 5]

И вот я думаю как правильнее сделать реакцию на такую ситуацию в стеке ТСР.

 

Правильно - посылать данные дальше (которые новые). Однако, неподтвержденные данные надо сохранять, отбрасывать их только после подтверждения.

[dimka76 64]

Спасибо всем. Буду реализовывать.

[Berkl 0]

 

Приветствую,

 

отдельную тему не стал создавать, поскольку тоже про ACKи вопрос у меня.

 

Исходные условия.

 

1. Есть мой девайс, который работает по modbus/TCP, слейв

2. Запускаю коммуникацию под виндой, с пом. утилитки ModbusPoll. Тут всё хорошо

3. Запускаю коммуникацию под Убунтой. Вроде всё хорошо, почти...

 

В Убунте, открыв wireshark, вижу что с компа идет почти с каждым поллингом дублирующий ACK. Как избавится от них ? Погуглил, выяснил, Dup ACK посылается в случае если нарушена очередность следования TCP сегментов или если сегмент утерян. Сегменты очевидно не теряются, иначе были бы ошибки коммуникации. Не правильный порядок сегментов ? А чё тогда под виндой правильный выходит ? В приложение загрузил архив с обоими логами, сделанные и под виндой и в убунте. Я не вижу в чем отличия, глазу не за что зацепиться, а в убунте DUP ACKи идут... Причем они есть не на каждом поллинге.

 

Спасибо !

logs.rar

[SFx 0]

Я не вижу в чем отличия, глазу не за что зацепиться, а в убунте DUP ACKи идут... Причем они есть не на каждом поллинге.

 

Поле identification в IP пакете увеличилось на один, если нет никаких роутеров между устройствами, и iptables, есть смысл попробовать покопаться в опциях IP-TCP у убунты. попробовать на другом диструбутиве. возможно включена некая эксперементальная фича, которая не совсем нормально работает. В обще, конечно, стек должен такие вещи отрабатывать. попробуйте поглядеть сессия ubuntu-ubuntu и win-ubuntu.

[Berkl 0]

Поле identification в IP пакете увеличилось на один, если нет никаких роутеров между устройствами, и iptables, есть смысл попробовать покопаться в опциях IP-TCP у убунты. попробовать на другом диструбутиве. возможно включена некая эксперементальная фича, которая не совсем нормально работает. В обще, конечно, стек должен такие вещи отрабатывать. попробуйте поглядеть сессия ubuntu-ubuntu и win-ubuntu.

 

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

Похоже да, что-то со стеком Убунты, его настройками. Попалась консольная утилитка TCP мастера http://www.modbusdriver.com/modpoll.html, она и на винду и на Линукс. Решил для чистоты экперимента её попробовать. Получилось тоже самое только еще более выражено: под виндой всё тикает. Перезагружаюсь под Убунтой. Тот же долбанный ACK Dup появился, а modpoll вобще подавилась ею. Выдала сообщение "I/O Error!" и встала после первого же поллинга :smile3046: .

 

Такие дела. Буду думать, спасибо за ответ