Форум Микро-Чип
Поиск и заказ электронных компонентов
 

Вернуться   Форум Микро-Чип > Cетевые протоколы и технологии

Cетевые протоколы и технологии TCP/IP стек

Ответ
 
Опции темы Опции просмотра
Старый 26.12.2016, 15:13   #1
Petr
Senior Member
 
Аватар для Petr
 
Регистрация: 25.02.2007
Возраст: 46
Сообщений: 1,734
Вес репутации: 3438/90
Petr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond repute
По умолчанию Снова проблема ожидания ACK в LwIP с другого боку.

Это продолжение вот этой темы:
http://www.microchip.su/showthread.php?t=17587
Суть там сводилась к тому, что RAW интерфейс предполагает вызов обработчика по приходу ACK (по любому активному TCP соединению).
Как следствие выявилось огромное падение скорости.
Вызвано оно параметром TCP_Delay реализации стека на другой стороне.
Общепринятым нынче (как выяснилось только для десктоп систем) является ситуация,
когда ACK посылается при получении полного окна (заявленного при открытии TCP) или 2-х пакетов (любой длины). В LwIP это константа.

Или если пакет был меньше (а полно ситуаций, когда его нечем дополнить до размера окна) - ACK приходит (отсылается получающей стороной) по истечении 5-10 мс.
Это многократно (тысячекратно) тормозит обмен.
Я решил проблему разбивая все пакеты на 2 части. (первый пакет не ожидает ACK). Скорость вышла на расчетный уровень.

Но теперь выяснилась трудность с Android и IOS.
В их реализации TCP ACK посылается всегда на каждый пакет независимо от размера окна или количества полученных пакетов.
Конечно приложение может изменить режим, но я работаю с браузером (например). И он этот параметр по умолчанию не меняет (никакой ни в какой мобильной ОС).
Значит мой первый пакет (половинка) получает ACK (что вызывает генерацию снова 2-х половинок одного пакета).
Происходит потеря пакетов. Не всегда, но стабильно часто.
Это наблюдается и в локальной сети с Wi-Fi, и при доступе через оператора связи.

На данный момент я решил проблему так:
В реализации HTTP сервера (фактически нужен только он) я анализирую заголовок "User-Agent:"
И если в параметре далее есть "Mobile" или "Tablet" - я перехожу в режим ожидания ACK для каждого посланного в TCP соединение пакета.

Это хорошо работает на имеющемся оборудовании.

Но!
Метод то "так себе".
И методика определения проблемы не очень стабильна, и она не
годится для других протоколов.
Я же могу захотеть пользоваться FTP с Android.
И там проблема вылезет снова во всей красе.

На иностранных сайтах все обсуждают эту проблему LwIP,
но никто не предлагает вменяемого решения.

Кто что думает на эту тему?

Последний раз редактировалось Petr; 26.12.2016 в 15:20.
Petr вне форума   Ответить с цитированием
Старый 29.12.2016, 12:46   #2
Petr
Senior Member
 
Аватар для Petr
 
Регистрация: 25.02.2007
Возраст: 46
Сообщений: 1,734
Вес репутации: 3438/90
Petr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Что выяснил по теме.

Интерфейс RAW в принципе не может быть свободен от этой проблемы.
Поскольку идеология "плавающего окна" TCP соединения
предполагает отправку ACK по разным (часто еще более сложным)
алгоритмам, чем один ACK на один или пару пакетов.

Проблема неплохо решена и в LwIP в реализации интерфейса сокетов (sockets.c).
По сути адекватное поведение "окна" реализовано в tcpip.c в
отдельном треде.
К сожалению это предполагает использование ОС (#define NO_SYS 0),
что для меня крайне неудобно.

Можно отказаться от использования именно ОС.
Поскольку это предполагает не столь уж глубокую переделку стека LwIP.
Но все же потребует усилий.

Как крайний вариант - можно использовать ОС.
Мое мнение - ОС это бессмысленный расход ресурсов, защищающий
от неумения программиста планировать структуру приложения.
Вносит существенную долю нестабильности в систему и
увеличивает время отладки проекта в разы.
Но это уже чисто мое личное мнение.
Petr вне форума   Ответить с цитированием
Старый 29.12.2016, 13:59   #3
Pridnya
Senior Member
 
Регистрация: 21.01.2009
Возраст: 38
Сообщений: 4,422
Вес репутации: 4370/119
Pridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Цитата:
Сообщение от Petr Посмотреть сообщение
К сожалению это предполагает использование ОС (#define NO_SYS 0),
что для меня крайне неудобно.
Если только ввиду многолетнего опыта неиспользования RTOS. Я сам только несколько примеров пробовал запускать и как и ты не использую пока чужие оси. А так - использование LwIP совместно с RTOS упрощает разработку TCP/IP приложений. И вообще новый мир откроется, как бы наступит просветление.
Цитата:
Сообщение от Petr Посмотреть сообщение
Можно отказаться от использования именно ОС.
Поскольку это предполагает не столь уж глубокую переделку стека LwIP.
Но все же потребует усилий.
В том-то и суть стека, что его переделывать не нужно - нужно настраивать и использовать. Если отказаться от ОС, то из стека можно добрую половину всего кода выбросить, лишившись при этом двух верхних уровней API (всего их три уровня). В этом мало чего хорошего.
Цитата:
Сообщение от Petr Посмотреть сообщение
Как крайний вариант - можно использовать ОС.
Мое мнение - ОС это бессмысленный расход ресурсов, защищающий
от неумения программиста планировать структуру приложения.
Вносит существенную долю нестабильности в систему и
увеличивает время отладки проекта в разы.
Но это уже чисто мое личное мнение.
Как раз нет. Твое мнение могло сложиться много лет назад ввиду использования старой глючной оси.
Для нормальных осей есть специальные программы, которые мониторят ось, упрощают отладку. Я так периодически интересуюсь.

Почитай, как товарищ переписывал TNKernel и сколько в ней было косяков, и как в конце концов он написал новую ось TNeo добавил новые возможности. И как же со старой осью люди работали (она глючила), но её даже хвалили. Интересная статья, даже я заинтересовался. И порты есть для PIC24-32, STM32. Я все хочу освоить.
__________________
Прогресс неизбежен.
Pridnya вне форума   Ответить с цитированием
Старый 29.12.2016, 15:19   #4
Petr
Senior Member
 
Аватар для Petr
 
Регистрация: 25.02.2007
Возраст: 46
Сообщений: 1,734
Вес репутации: 3438/90
Petr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Цитата:
Сообщение от Pridnya Посмотреть сообщение
Твое мнение могло сложиться много лет назад ввиду использования старой глючной оси.
Для нормальных осей есть специальные программы, которые мониторят ось, упрощают отладку. Я так периодически интересуюсь.

Почитай, как товарищ переписывал TNKernel и сколько в ней было косяков, и как в конце концов он написал новую ось TNeo добавил новые возможности. И как же со старой осью люди работали (она глючила), но её даже хвалили. Интересная статья, даже я заинтересовался. И порты есть для PIC24-32, STM32. Я все хочу освоить.
Может ты и прав (я использовал именно TNKernel в паре проектов).
Но главный итог этого опыта - я не понял зачем я это использовал!
Да, были глюки и мои и возможно TNKernel. Было потрачено время на нахождение и их решение.
Отметем трудности с освоением и глюки.
Все работает чудесно и сразу!

И тут я снова задаюсь вопросом "зачем".
Ответ то ясен - "задачи переключать".
А я умею выполнять любые задачи в контроллере без трудностей.
Ожидать любые события и т.д. без влияния на другие процессы.
И что мне теперь делать? Использовать ось только потому, что другие этого не умеют?
Я лучше LwIP перепишу.
Мне его код тоже не нравится, как и тому товарищу код TNKernel.
А если я этого не сделаю (а воткну ось) - значит у меня будет целых 2 либы, код которых мне не нравится
Petr вне форума   Ответить с цитированием
Старый 29.12.2016, 16:16   #5
Driver
Senior Member
 
Регистрация: 25.02.2007
Адрес: picping.lg.ua
Возраст: 51
Сообщений: 205
Вес репутации: 1120/52
Driver has much to be proud ofDriver has much to be proud ofDriver has much to be proud ofDriver has much to be proud ofDriver has much to be proud ofDriver has much to be proud ofDriver has much to be proud ofDriver has much to be proud ofDriver has much to be proud of
Отправить сообщение для Driver с помощью ICQ Отправить сообщение для Driver с помощью Skype™
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

В своем стеке тоже столкнулся с похожим. Делал так - отсылал пакеты с данными , невзирая на аск . Между пакетами небольшая пауза, около 1 мс +/-; как раз другую задачу лопатил. Далее если аск пришел - корректируем счетчики, не пришел аск по концу передачи (PUSH) - начинаю передавать всю страницу с начала, предварительно запомнив счетчики в начале первой передачи.
Памяти нет в пике (при моих остальных задачах) хранить пропущенные пакеты, передаю с начала с теми же номерами, приемная сторона все равно отбракует как дубликат.
Клиенты работают быстро и на WIN и на андроид.

Далее, практически все браузеры открывают 4-8 сессий одновременно, все входящие SYN отрабатываю и в стек, на удержание , пока первый файл не уйдет, на удержании. Если пришли аски пустые - подтверждаю, держу сессию. Далее по очереди выгружаю файлы. Если давать отлуп или молчать на новые сессии - скорость обмена падает в десятки раз.
__________________
Все, что нельзя запрограммировать на ассемблере,приходится паять...
Driver вне форума   Ответить с цитированием
Старый 29.12.2016, 16:30   #6
Greg
Super Moderator
 
Регистрация: 25.02.2007
Адрес: Moscow, ODBS
Сообщений: 6,639
Вес репутации: 5137/156
Greg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond reputeGreg has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Цитата:
Сообщение от Petr Посмотреть сообщение
И тут я снова задаюсь вопросом "зачем".
Ответ то ясен - "задачи переключать".
А я умею выполнять любые задачи в контроллере без трудностей.
затем же, зачем придумали плюсы - распараллелить разработку. лучшая ртос - это прерывания. но это на одного и write-only.
Greg вне форума   Ответить с цитированием
Старый 29.12.2016, 16:57   #7
Petr
Senior Member
 
Аватар для Petr
 
Регистрация: 25.02.2007
Возраст: 46
Сообщений: 1,734
Вес репутации: 3438/90
Petr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Цитата:
Сообщение от Greg Посмотреть сообщение
затем же, зачем придумали плюсы - распараллелить разработку. лучшая ртос - это прерывания. но это на одного и write-only.
Я как то по наивности до сих пор использовал "плюсы"
исключительно как средство создания многих копий объекта и
возможности "наследования" свойств и методов объекта.
Это меня все "Отцы" с толку сбили!
Не сказали, что это придумано для распараллеливания разработки

А про одного - это верно подмечено!
Я действительно ни разу не командный игрок.

Хотя реклама TNeo ине понравилась.
Я воткну на досуге ее в проект и включу сокеты либы.
Посмотрю что будет со скоростью обмена.

Пока я вынес подготовку пакетов из коллбеков. Делаю паузу между передачей 1-го и 2-го пакета цепочки в 1 мс. Приход ACK отрабатывается корректно, я не освобождаю буфер до его прихода для обеспечения возможности запроса повторной отправки (потеря пакетов).
Таймауты выбрал почти произвольно.
Все корректно работает на win и на мобилах. Потеря пакетов по Wi-Fi не происходит.
Скорость высока и устраивает, хотя я и понимаю, что не максимально достижима, поскольку есть паузы.
Но это реализация "окна" "на коленке" и "по быстрому".
Уверен, что реализация TCP в треде LwIP более продуманна.
Посмотрим.
Во всяком случае исходный код TNeo не вызывает отвращения. Что уже хорошо.
Petr вне форума   Ответить с цитированием
Старый 29.12.2016, 20:49   #8
Pridnya
Senior Member
 
Регистрация: 21.01.2009
Возраст: 38
Сообщений: 4,422
Вес репутации: 4370/119
Pridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond reputePridnya has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Цитата:
Сообщение от Petr Посмотреть сообщение
Может ты и прав (я использовал именно TNKernel в паре проектов).
Но главный итог этого опыта - я не понял зачем я это использовал!
...
И тут я снова задаюсь вопросом "зачем".
Ответ то ясен - "задачи переключать".
А я умею выполнять любые задачи в контроллере без трудностей.
Ожидать любые события и т.д. без влияния на другие процессы.
И что мне теперь делать? Использовать ось только потому, что другие этого не умеют?
В то время TNKernel была совсем не такая как сейчас TNeo, её глючность была подтверждена и локализована, затем она значительно изменилась и автор правок решил сменить название. Я не знаю, знал ли автор предыдущей версии оси об этих глюках или нет, может быть у него даже была более стабильная версия, которую он не выкладывал как опенсорц. А вот автор правок сделал хорошее описание, выложил описание, исходники. Со слов автора ось получилась надежная и быстрая в сравнении с другой популярной осью. Только вот лицензия той же популярной FrееRTOS не позволяет сравнивать её с другими осями и публиковать результаты (и та же FrееRTOS - это всего лишь первая ступенька - замануха-букварь, вторая ступенька OpеnRTOS, третья - SafеRTOS, сертифицированная, безопасная и платная). Кстати, иногда встречаются объявления с предложениями работы, где требуется знание FrееRTOS или другой аналогичной Rtos. Использование полноценных Rtos (которые идут в комплекте со своими периферийными библиотеками, стеками...) для современных микроконтроллеров дает ряд преимуществ, поэтому они существуют, продаются, применяются, а иначе этих Rtos давно бы не было.
Цитата:
Сообщение от Petr Посмотреть сообщение
Я лучше LwIP перепишу.
Так тот же LwIP имеет три уровня API, каждый из которых использует предыдущий, причем два верхних уровня предполагают использование RTOS. В общем как не переписывай - придешь к RTOS. Лишь бы время хватило на переписывание.
__________________
Прогресс неизбежен.
Pridnya вне форума   Ответить с цитированием
Старый 30.12.2016, 08:09   #9
Petr
Senior Member
 
Аватар для Petr
 
Регистрация: 25.02.2007
Возраст: 46
Сообщений: 1,734
Вес репутации: 3438/90
Petr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond reputePetr has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Цитата:
Сообщение от Pridnya Посмотреть сообщение
(которые идут в комплекте со своими периферийными библиотеками, стеками...)
Вот!!!

Ценность и смысл операционной системы именно в отделении
программиста от периферии. На которую доки уже почитали,
эрраты все учли и написали удобные функции, которые делают
то, что и должны делать.
Никому же из программистов игр не приходит в голову читать
все! доки на графические чипсеты всех! производителей.
Это просто остановило бы всю отрасль.
Они читают доку на OpenGL.
А доки читают создатели драйверов.
И с переменным успехом это все работает.

В нашей области ситуация не столь уж иная.
Понятно, что раз ты сделал некое свое железо на плате -
тебе его и поддерживать в софте.
Но это не значит, что ты должен еще тратить время на изучение
доки на модуль Ethernet контроллера. Которая сама по себе 500
страниц. Можно и операционку или либу взять,
поскольку четко известно что должен делать этот модуль и как именно.

И вот именно это и стоит денег и имеет смысл.

А только задачи переключать....
Зато как звучит "операционная система..."
Или "я тут написал операционную систему, великодушно дарю"
Petr вне форума   Ответить с цитированием
Старый 30.12.2016, 10:47   #10
Рак
Senior Member
 
Регистрация: 02.04.2008
Адрес: Кременчуг
Возраст: 31
Сообщений: 1,289
Вес репутации: 2210/69
Рак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond reputeРак has a reputation beyond repute
По умолчанию Re: Снова проблема ожидания ACK в LwIP с другого боку.

Цитата:
Сообщение от Pridnya Посмотреть сообщение
В то время TNKernel была совсем не такая как сейчас TNeo, её глючность была подтверждена и локализована, затем она значительно изменилась и автор правок решил сменить название. Я не знаю, знал ли автор предыдущей версии оси об этих глюках или нет, может быть у него даже была более стабильная версия, которую он не выкладывал как опенсорц. А вот автор правок сделал хорошее описание, выложил описание, исходники. Со слов автора ось получилась надежная и быстрая в сравнении с другой популярной осью. Только вот лицензия той же популярной FrееRTOS не позволяет сравнивать её с другими осями и публиковать результаты (и та же FrееRTOS - это всего лишь первая ступенька - замануха-букварь, вторая ступенька OpеnRTOS, третья - SafеRTOS, сертифицированная, безопасная и платная). Кстати, иногда встречаются объявления с предложениями работы, где требуется знание FrееRTOS или другой аналогичной Rtos. Использование полноценных Rtos (которые идут в комплекте со своими периферийными библиотеками, стеками...) для современных микроконтроллеров дает ряд преимуществ, поэтому они существуют, продаются, применяются, а иначе этих Rtos давно бы не было.
Спасибо за обзор.
Еще существуют как говорится "хорошо извесные в узком кругу", для мед. направления, напимер, там свои RTOS, производитель подтверждает это сертификатами. Кардиостимуляторы, носимые инсулиновые помпы и кардиографы - это все уже работает с использование RTOS. С месяц назад была даже статья с призывам переностить софт, связанный с жизнеобеспечением, в опенсорц для выявления проблем в коде.
Рак вне форума   Ответить с цитированием
Ответ


Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 
Опции темы
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Часовой пояс GMT +3, время: 06:03.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd. Перевод: zCarot