Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Ограничение стека OpenTCP
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Fast Ethernet/Gigabit Ethernet/FibreChannel
berkl
Привет всем!

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

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

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

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

Заранее благодарен.
wolfman
Поищите програмку analizerXP, там какие-то настройки можно было задавать. По моему, по умолчанию винда гонит пакеты размером 1500 байт. Могу ошибаться.
kolobok0
Цитата(berkl @ May 24 2012, 14:09) *
...сегментированные TCP пакеты...


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

berkl
Цитата(wolfman @ May 24 2012, 21:48) *
Поищите програмку analizerXP, там какие-то настройки можно было задавать. По моему, по умолчанию винда гонит пакеты размером 1500 байт. Могу ошибаться.


Поищу, спасибо. Да, обычные езернет пакеты имеют максимум 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 данные? Вероятно где-то этот размер настраивается, вто это и хочу выяснить.

Цитата(kolobok0 @ May 24 2012, 23:20) *
написали ерунду.
TCP пакетов в природе нет. это раз.
два - вы наверное говорите о сегментировании на уровне IP? То да, в открытых стэках на IP уровнях пакеты не собираются. разрезанные херятся.


Я может не сильно искушен в сетевой терминологии, но вы уважаемый, возможно будете удивлены, если хотя бы в Яндексе наберете словосочетание "TCP пакет".
Херятся верно, нет ни поддержки IP фрагментации, ни TCP сегментации. У меня и пост собственно называется Ограничение стека OpenTCP, но надо что-то делать, вот я спрашиваю, кто знает.
andrewlekar
590 байт ограничение, скорее всего, выставляет ваше устройство в поле MSS.
berkl
Цитата(andrewlekar @ May 25 2012, 09:28) *
590 байт ограничение, скорее всего, выставляет ваше устройство в поле MSS.


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

590 байт у меня нигде не выставляется.
andrewlekar
Там не видно, после window size есть поле options? MSS в нём устанавливается. Можете его явно установить и ещё в IP пакете в поле FLAGS попробуйте установить Do Not Fragment.
berkl
Цитата(andrewlekar @ May 25 2012, 15:04) *
Там не видно, после window size есть поле options? MSS в нём устанавливается. Можете его явно установить и ещё в IP пакете в поле FLAGS попробуйте установить Do Not Fragment.


Благодарю!

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

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

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


Еще раз снкс за подсказку с MSS
kolobok0
Цитата(berkl @ May 25 2012, 08:01) *
...возможно будете удивлены, если хотя бы в Яндексе наберете словосочетание "TCP пакет"....


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

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

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

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

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

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

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

удачи вам.
berkl
Цитата
и хде слово о пакетах???


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

Вот к примеру из руководства на 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 подкинул мне идею, за что я его уже искренне отблагодарил.

Цитата
фрагментации на уровне TCP нет в помине.

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

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


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

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

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

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

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


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

Цитата
Смещение данных

Это поле определяет размер заголовка пакета TCP в 4-байтных (4-октетных) словах. Минимальный размер составляет 5 слов, а максимальный — 15, что составляет 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.



Цитата(KRS @ May 31 2012, 01:37) *
berkl,
посмотрите размер окна, может быть с этим связано
(wireshark его показывает.)


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


Всем Добра и удачи!
wolfman
Цитата(berkl @ May 30 2012, 22:50) *
Да и самому стек писать, думается, дело нынче не благодарное.
Я тут был в Терреэлектронике, побалтали чуток про всякое. Говорят "самописцев" становится всё меньше, а линуксоидов всё больше. МКУ постоянно дешевеют и мощнеют... Проще мол один раз разобраться с Линуксом, взять готовый порт Линукса под целевой проц и полностью сконцентрироваться на задаче заказчика. Они считают это уже сформировавшимся трендом, судят по своим продажам.

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


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

Если интересно могу поспрашать у программеров.
berkl
Цитата(wolfman @ Jun 1 2012, 15:59) *
У нас как-то из линукса стек вытащили, у нас правда Атмель в качестве проца.

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



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

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


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

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


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


Поговорил с программером, наврал я вам слегка. Они взяли пакет UIP и его прикрутили, вроде бы пока хватает.
Проц. AT91SAM7X256.
Ndf
Цитата(wolfman @ Jun 4 2012, 17:57) *
...Они взяли пакет UIP и его прикрутили, вроде бы пока хватает.Проц. AT91SAM7X256.

Для справки, к EVB на AT91SAM7X256 идет диск с "Basic EMAC uIP project", так что непонятно что они там прикручивали sm.gif .
wolfman
Цитата(Ndf @ Jun 5 2012, 01:21) *
Для справки, к EVB на AT91SAM7X256 идет диск с "Basic EMAC uIP project", так что непонятно что они там прикручивали sm.gif .

А кто вам сказал, что покупалась EVB?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.