Привет всем!

Есть такая проблемка.

Я использую стек OpenTCP для передачи данных HTTP. Там всё работает, но вот упёрся в ограничение. Дело в том что OpenTCP не поддерживает сегментированные TCP пакеты, а копм их шлёт девайсу, в методе GET. Размер езернет пакета ТСP сегмента- 590 байт максимум. Мне бы помогло если бы я смог сказать Винде (у меня XP) увеличить этот порог, скажем 1000 байт, тем самым избавился бы от проблемы с сегментацией.

Кто знает как увеличить размер фрагмента?

Или может кто работал с OpenTCP и знает как это дело обходится применительно к данному стеку?

Заранее благодарен.

Сообщение отредактировал berkl - May 24 2012, 10:58

Поищите програмку analizerXP, там какие-то настройки можно было задавать. По моему, по умолчанию винда гонит пакеты размером 1500 байт. Могу ошибаться.

написали ерунду.
TCP пакетов в природе нет. это раз.
два - вы наверное говорите о сегментировании на уровне IP? То да, в открытых стэках на IP уровнях пакеты не собираются. разрезанные херятся.

Поищу, спасибо. Да, обычные езернет пакеты имеют максимум 1526 байт. Деление данных IP протокола в езернет сетях есть IP фрагментация. Но комп мне передает TCP данные, в которых за раз передается менее 1526 байт. То есть IP фрагментация в данном случае вообще не актуальна.

Имеет место TCP сегментация, вот от неё и надо мне избавиться. Гляньте плз на мой скриншот лога Wireshark.
IP компа - 192.168.1.200
IP девайса - 192.168.1.1

Видно, что комп посылает данные по HTTP, методом GET, строки 4 и 5. Сначала идёт сегмент в 590 байт, потом посылает остатки которые не влезли в предыдущий сегмент. Вот здесь и вопрос. На кой он так мелко (по 590 байт) нарезает TCP данные? Вероятно где-то этот размер настраивается, вто это и хочу выяснить.



Я может не сильно искушен в сетевой терминологии, но вы уважаемый, возможно будете удивлены, если хотя бы в Яндексе наберете словосочетание "TCP пакет".
Херятся верно, нет ни поддержки IP фрагментации, ни TCP сегментации. У меня и пост собственно называется Ограничение стека OpenTCP, но надо что-то делать, вот я спрашиваю, кто знает.

590 байт ограничение, скорее всего, выставляет ваше устройство в поле MSS.

Хм... Вроде не вижу ничего такого. Гляньте плз. Сеанс связи начинается с посылки компом запроса на соединение (флаг SYN, первая строка). Я отвечаю ему ACKом (вторая строка) и дальше с компа полетели нарезанные TCP сегменты. Единственное что я шлю компу - это размер TCP окна - 1400 байт (вторая строка).

590 байт у меня нигде не выставляется.

Там не видно, после window size есть поле options? MSS в нём устанавливается. Можете его явно установить и ещё в IP пакете в поле FLAGS попробуйте установить Do Not Fragment.

Благодарю!

У меня нет поля MSS. То есть я не шлю опции ТCP вобще. Почитал тут, опции эти не являются обязательными, вот они у меня и не посылаются. Если опции TCP не указываются, то сторона принявшая такой пакет (в моём случае комп) будет посылать в ответ ТСР пакеты, сегментированные по умолчанию по 536 байт данных в каждом, езернет пакет 590 байт получется. OpenTCP игнорирует все TCP опции которые ему посылаются и сам он их не посылает. В конечном счёте это и есть ограничение, мешающее жить, а не отсутствие фрагментрирования и сегментирования.

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

Второй путь проще и предпочтительнее на данный момент для меня. Не подскажите где?


Еще раз снкс за подсказку с MSS

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

"TCP — это транспортный механизм, предоставляющий поток данных.."

и хде слово о пакетах???

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

ещё раз:
На пользовательском уровне НЕТ понятия пакетов. если мне не верите - загляните в RFC (надеюсь этот документ на данный протокол даст исчерпывающую инфу вам). Но даже копнув википедию на бытовом уровне - вы не найдёте упоминания пакетов на пользовательском уровне. сами же пакеты - скрыты в реализации протокола.

возвращаясь к баранам...
фрагментации на уровне TCP нет в помине. Вы же сами привели сканы. Вот и глядя на них ответьте где находятся смещения и размеры фрагментов??? Правильно, у IP пакета. я вам более скажу - они могут резаться как душе угодно на проходящих хопах. например в настраиваемом оборудовании поставить размер в 100 байт - будут резаться по 100 байт. Т.е. если Вы, по пути следования пакетов где либо зарежите стандартный размер 1500 байт - то будет вам счастье. точнее не счастье. да, винда режит на передачу. на приём она может максимум словить (зависит от нагрузки) - 65535 байт без проблем.

если Вы хотите работать без проблем - делайте правильный стэк TCP. Готовый увы - я в своё время не нашёл. Да и ещё. Если это решение для МК(или типа того) - то без внешней ОЗУ не прокатит (ну почти). Т.к. объём ОЗУ сильно зависит от нагрузки * время хранения фрагментов. т.е. чем больше ОЗУ тем больше нагрузку протащите.

удачи вам.

В этой ссылке допустим нет, в остальных тоже не видите?

Вот к примеру из руководства на Wireshark:

http://academy.delmar.edu/Courses/ITSY2430...#ChWorkSelPack1

Или вот нашел маленькую разъеснялку про ограничения моего (в смысле OpenTCP) стека, тут тоже встретите "TCP packet" ...

http://read.pudn.com/downloads155/doc/comm...App_%20Note.pdf


"если Вы вчитаетесь в свой первый пост где речь идёт об использовании данного протокола (вы рассуждаете о HTTP и иже верхних уровнях) - то в ваших рассуждениях смешались кони-люди."

HTTP - это место в котором я упёрся в проблему. Проблема как оказалась не в HTTP, и не в фрагментации и сегментации, но я ж не знал этого!
andrewlekar подкинул мне идею, за что я его уже искренне отблагодарил.


Я уже разобрался что есть IP фрагментация и что TCP сегментация (мой пост May 25 2012, 08:01 )



Да он неплохо работает та, тьфу, тьфу. TCP Модбас модбасит, веб странички показывает, ФТП написал под него с нуля за недельку, почту отсылает по STMP, нескольких TCP клиентов поддерживает... что еще надо девайсу на ПИКе? Да, входящие нарезанные по 100 байт пакеты будут для меня проблемой, но встроенный девайс вроде моего, как правило, работает с короткими фреймами входящих данных. Во всяком случае я впервые столкнулся с ситуацией, когда встроенный девайс должен принять данные в несколько сотен байт.
Ну в целом, не такая уж большая проблема у меня чтобы бросать то что уже отработано и писать своё, всё с нуля! Да и самому стек писать, думается, дело нынче не благодарное.
Я тут был в Терреэлектронике, побалтали чуток про всякое. Говорят "самописцев" становится всё меньше, а линуксоидов всё больше. МКУ постоянно дешевеют и мощнеют... Проще мол один раз разобраться с Линуксом, взять готовый порт Линукса под целевой проц и полностью сконцентрироваться на задаче заказчика. Они считают это уже сформировавшимся трендом, судят по своим продажам.

Всего наилучшего.

berkl,
посмотрите размер окна, может быть с этим связано
(wireshark его показывает.)

Полистал вашу ссылочку, да вот же к примеру :






С окнами всё нормально. Проблема в отсутствии TCP опций в пакетах, мною отсылаемых. Всё-таки придётся допиливать стек. Разобрался, пора закрывать темку.


Всем Добра и удачи!

У нас как-то из линукса стек вытащили, у нас правда Атмель в качестве проца.

Если интересно могу поспрашать у программеров.

Думаю с полным функционалом его не перенести на 16 битный проц c 16кб ОЗУ, вроде PIC24/dsPI33. Получится некий кастрат, вроде моего OpenTCP... Смысл? Надо уж брать тогда Линукс целиком мне каааца, и проц с MMU. Цены на "линуксовые" процы весьма похорошели уже. AT91SAM9260 (200MIPS) в розницу 326 рэ в Терре... Моя ПИКа (16MIPS) стОит рублей 200!

Но всё равно интерсно! Спросите плз, на какой Атмель ваши программеры его портировали и почему выбор пал именно на этот путь (выдёргивание стека из Линкуса). Ну и получен ли был желаемый результат.


Заранее благодарен.

Поговорил с программером, наврал я вам слегка. Они взяли пакет UIP и его прикрутили, вроде бы пока хватает.
Проц. AT91SAM7X256.