Продолжаю мучать LWIP.

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

Во первых, почему-то все мои фреймы имеют ошибку Frame Check Sequence.

Во-вторых очень много Retransmitoв. Такое ощущение что клиент мгновенно начинает слать повторные запросы. Это может быть связано с первой проблемой?

В приложении Wireshark trace запроса.

Что значит к роутеру? Плату в lan роутера, wan роутера в лок. сеть? Если так то плата ни причем, контрольные суммы ethernet в этом случае генерит роутер.

Нет, и комп и плата были подключены к LAN портам роутера. С контрольными суммами разобрался, эту ошибку исправил. Была ошибка в драйвере.

Я правильно понимаю, что wireshark не всегда правильно отображает порядок следования пакетов? Или это роутер их местами путает? Тогда к повторным запросам вопров нет.

Сейчас я пришел к тому, что у меня вопрос к следующему коду:


Может мне стоит повнимательнее посмотреть на netconn_write, как она работает - пока что если я убираю DELAY_Ms, то все падает на втором netconn_write.

Роутер тут скорей всего нипричем. В любом случае изменение порядка следования пакетов в tcp соединении это не преступление - принимающая сторона должна(если позволяют ресурсы) принять все пакеты, высторить их по-порядку и отправить ask.
У меня тоже бывало нарушение порядка пакетов, но к ретрансмитам это не приводило. Кстати попробуйте, для проверки, установить в конфигурации TCP_WND (1 * TCP_MSS) (ищите в lwipopts.h если его там нет то или добавьте или меняйте непосредственно в opt.h) это уберет окно и порядок пакетов точно не будет нарушен.
Да, и смотрите за кодом возврата netconn_write - там ведь может быть и разрыв соединения и нехватка памяти.

а кто же причем? конечно рутер, если по вайфаю слать то вообще бардак с порядком пакетов будет... Но как было сказано ТСР следит за очередностью пакетов. И ретрансмиты понятное следование другого порядка пакетов потому что в обмене всегда идет указатель какой кусок данных записывается, и если не сохранены данные Н, а приходят Н+1, принимающая сторона их отвергнет и попросит повторить Н пакет.

А вот от окна отказываться не стоит, без него все грустно и медленно становится...

кстати если подтверждение пакета (сегмента) не приходит за заданное время будет ретрансмит, может время жизни пакетов увеличить?

Да, комп у меня по вайфаю с роутером общается. Да, за результатом netconn-write надо следить, это недосмотр. Время жизни - насколько я понимаю, у меня первые ретрансмиты исходят из клиента, а не из моей платы. Кроме того, время жизни вроде меряется в кол-ве сегментов которые он может пересечь, т.е. кол-во роутеров на пути от клиента к серверу, вроде это ни на что повлиять не сможет.

Спасибо.

вроде это просто время а не число скачков...

вай-фай злобный менятель пакетов местами)... для ТСР - это тормозилка, пакеты могут только последовательно приниматься....

Я где-то читал, что TTL изначально задумывался как время, но потом стали использовать как hop count. каждый роутер при передаче пакета вычитает один и отдает дальше. Если ноль, то выкидывают пакет.

Подключил к свичу комп напрямую, без вайфая - все чисто. Никаких дубликатов. Что ж так странно вайфай работает, зачем он пакеты местами путает? Сама по себе поремена пакетов местами мой сервер не должна смущать, т.к. мы получаем все запросы одно-пакетные - SYN, ACK, GET HTTP. То, что ACKи приходят в случайном порядке, это ок для lwip?

В общем случае, это видимо не верно. Ничто не мешает стэку принять пакеты и упорядочить их самостоятельно. Вы имеете ввиду для lwip?

Это он воду мутит, негодяй. В lwip есть настройка, которая включает/выключает обработку пакетов TCP вне очереди. Вроде бы называется OOSEQ (Out Of Sequence).

не! тут надо разделить протоколы.

TCP/IP - этот протокол гарантирует последовательность приема данных, отсутствие повторов и пропусков. И добивается он этого как раз строго последовательным приемом. В каждой посылке идет адрес не принятой части и подтверждается принятая.
то есть к примеру
в начале идет пакет 10 байт в нем написа с 0 байта, 0 подтверждено
в ответ на этот пакет идет к примеру 5 байт обратно и в них уже стоит с 0 байта, 10 подтверждено
в ответ на это ... с 10 байта, 5 подтверждено.

если будет подтверждено прием 10 байт, и придет пакет с 20 байта, то ТСР скажет ай ай ай, и попросит повторить с 10, оттуда и появляется ретрансмит в случае перестановки пакетов.

ТСР не может принять с 20 байта, а потом ждать когда дошлют с 10 по 20, потому что у него есть проверка на повторные данные.
то есть если подтверждено 15 байт, то любые попытки послать пакет с 5 байта игнорируются, а это может работать только если до 15 байта нет дырок.

Это как бы принцип работы ТСР.

Но есть же еще UDP, у него нет не начала не конца, он может терять пакет и переставлять его как хочет. Видимо вайфай обрабатывает пакеты по их длине или еще как - то, и какие то уходят быстрее, если они УДП пакеты то и славно, а если ТСР, то ТСР сам все поправит. Думаю так.

Кстати надеяться на то что пакеты пойду одним пакетом можно только если у вас длина данных меньше 56 байт по моему, все что больше может быть рутером разбито, там есть атрибут запрета разбития пакетов, но не вссе его могут обрабатывать... макс длинна пакета около 1500 байт, а в вайфай кажется больше 560 не лезет...

Отсюда резюме! Если ТСР то все получится правильно не зависимо от длины пакетов. Если УДП, то надо накладывать протокол на данные внутри. как то так

Это где Вы такое вычитали? Во-первых принимающая сторона не просит повторить, это отправитель сам повторяет передачу если не дожидается ASK от получателя. Во-вторых принимающая сторона не отбрасывает H+1, а ждет H. Точней говоря отбрасывают только самые усеченные версии стеков которым просто некуда складировать пакеты.



В каждом пакете содержится порядковый номер в в потоке в байтах. Если к примеру пришел пакет с номером 100 длинной 50 байт, если в потоке нет разрывов то получатель отправляет подтверждение приема 150 байт, затем, к примеру, приходит пакет с номером 200 длинной 50 байт, то TCP понимает, что 50 байт где-то потерялось и ждет их. Затем когда пакет с номером 150 длинной 50 приходит получатель отправляет отправителю подтверждение приема 250 байт(Один раз!).
Сори напутал, порядковый номер это номер первого байта пакета, а не последнего. Отредактировал.

Вот именно что получатся лишние ретрансмиты при случайной задержке пакета. Нормальная реализация не должна сразу говорить "ай ай ай", т.к. перестановка - это вариант нормы.

Я с TCP/IP очень мало знаком, зато все знания свежайшие. При всем уважении, вы заблуждаетесь. TCP (и я говорю именно про TCP) прекрасно позволяет принимать пакеты вне очереди и упорядочивать. Более того, у него нет механизма запросить еще раз какой-то пакет. Он может отказаться ACKать данные с 20 байта пока 10-20 не получены, только и всего.



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


TCP_QUEUE_OOSEQ

Да, спасибо, она по умолчанию включена.

Сдаюсь сдаюсь...

Вы все действительно правы. И я погорячился насчет того что при появлении дырки в данных БУДЕТ ретрансмит. Правильнее будет сказать что НЕ БУДЕТ подтверждения С 20 байта пока НЕ БУДЕТ приняты данные с 0 до 20. При наличии достаточной памяти стэк действительно может придержать полученные сегменты пока не придет сегмент в дырку и поставить их всех по порядку.

А если памяти не достаточно, если памяти всего на 1 сегмент? Контроллер будет вынужден отбрасывать прочие сегменты, потому что у него просто не будет места их хранить, ждет то он вполне определенный сегмент.




где то я читал спецификацию, возможно это была спецификация на какой то конкретный wi-fi рутер или семейство, там было указано что сегменты более 5хх байт не пролазят. Не знаю почему сейчас мне кажется что это про все вай фаи идет речь, как то вот так в голове отложилось.

Но в любом случае в стандарте нет гарантии что весь максимально возможный пакет пойдет разом, есть только одно что любой пакет меньше 56 (теперь уже и в этой цифре сомневаюсь) быть не может, если данных меньше они нулями добиваются, и следовательно это минимальный пакет - не делим, все что больше - гарантий нет!

Вот посыпаю голову пеплом... наверное мои знания путаются между стандартом и конкретными реализациями в условиях ограниченных ресурсов.... постараюсь больше так не умничать

В этом случае он должен объявить свое окно соответсвуещего размера, и ему будут слать сегменты по одному.

то есть если окно 2 сегмента допустим
ему не смогут прислать сегменты в последовательность 2 3 1, только 1 - 2, или 2 - 1?

есть еще таймаут на подтверждение сегмента, неподтверждение сегмента в заданное время вызывает ретрансмит. тогда получается дело в этом было. Сегменты менялись местами, и возникала пауза на обработку больше заданной?

Окно задается в байтах, а сегменты могут быть любыми.

если окно к примеру 3 байта (что невозможно, но допустим),

и к вам придут сегменты в последовательности 2 1 3, и размер сегментов 2 байта,
то положив в буфер 2 сегмент, вы займете его так что принять сможете только половину 1,
2 сегмент будет выкинут чтобы влез 1 сегмент, и это вызовет последующий его ретрансмит...

или я где-то не так рассуждаю?