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

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

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

Ответ
 
Опции темы Опции просмотра
Старый 06.03.2017, 16:45   #1
Pasha_Bi
Senior Member
 
Регистрация: 24.07.2009
Адрес: г. Иваново
Возраст: 42
Сообщений: 256
Вес репутации: 617/37
Pasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to all
По умолчанию Конфигурация LwIP стека

Уважаемые знатоки LwIP стека!
Пользуюсь LwIP стеком v1.4.1 для микроконтроллеров STM32F4. Тип API - Netconn. Операционная система - FreeRTOS.
Задача: данные "пакуются" в пакеты по 1460 байт (равны максимальному размеру кадра Ethernet минус заголовки IP и TCP). В секунду требуется передать 4 пакета (на самом деле чуть чаще). Устройство передающее пакеты - сервер, приложение на ПК - клиент. При использовании транспортного уровня UDP пакеты не теряются. При использовании TCP тоже не теряются, если со стороны ПК загрузка небольшая. Если на ПК выполняется какая нибудь ресурсоемкая задача, 1-5% пакетов теряется.
Приложение со стороны ПК написано в Visual C++, для работы с сокетами используются API winsock2. Я не очень уверенно чувствую себя в программировании под Windows, и скорей всего не очень эффективно пользуюсь API для управления сокетами winsock2. В Windows приложении я организовал таймер, и в обработчике событий от таймера проверяю наличие новых данных. Соответственно в эти обработчики я попадаю крайне нерегулярно, в зависимости от загрузки CPU.
В TCP протоколе, когда клиент (приложение на ПК) не успевает читать из сокета пакет, не выдается сигнал подтверждения (ACK) и сервер (мое устройство) должен повторить пакет (или несколько пакетов, в зависимости от размера плавающего окна). Работает ли этот алгоритм (повторная передача пакетов при отсутствии ACK) на стороне сервера (на стороне моего устройства)? В файле конфигурации LwIP мне некоторые автоподстановки не совсем понятны. Приведу некоторые из них, поправьте, пожалуйста, если я неправильно их закомментировал или какие то настройки Вам покажутся нелепыми (понимаю, что все зависит от конкретной задачи, но все же...).
Код:
// Размер SRAM который может быть использован стеком LwIP
#define MEM_SIZE		(15*1024)
// Максимальное колличество используемых в проекте структур pbuf, использующих динамически выделяемую память
#define MEMP_NUM_PBUF           16
// Максимальное колличество управляющих структур TCP соединений (колличество возможных одновременно
// открытых соединений)
#define MEMP_NUM_TCP_PCB        1
// Максимальное колличество сокетов, которые предполагается одновременно слушать
#define MEMP_NUM_TCP_PCB_LISTEN 1
// Максимальное колличество TCP сегментов, одновременно находящихся в очереди для передачи. Это число
// связано с автоподстановками TCP_SND_BUF и TCP_SND_QUEUELEN
#define MEMP_NUM_TCP_SEG        16
// Максимальное колличество одновременных подсчетов таймаута. Непонятно с какой настройкой связать 
// эту автоподстановку. Возможно с колличеством одновременно возможных соединений. На всякий случай 
// не делаю эту автоподстановку равной 1.
#define MEMP_NUM_SYS_TIMEOUT    5
// Максимальное колличество используемых в проекте структур pbuf, используемых память POOL
#define PBUF_POOL_SIZE          16
// Размер POOL буфера. Я считаю рациональным использовать такой же размер POOL как и максимальный 
// размер полезной нагрузки
#define PBUF_POOL_BUFSIZE       (1500-40)
// Определяется, если требуется контроль очереди сегментов
#define TCP_QUEUE_OOSEQ         1
// Максимальный размер полезной нагрузки (1500 - размер заголовка TP - размер заголовка TCP)
#define TCP_MSS                 (1500-40)
// Максимальное колличество байт, которые могут быть поставлены в очередь для отправки 
// по TCP соединению при выполнении функции  tcp_write
#define TCP_SND_BUF             (8*TCP_MSS)
// Эта автоподстановка мне непонятна. Какая то еще одна очередь. Может быть очередь уже FreeRTOS для задачи
// передачи данных. Она должна быть как минимум (2*TCP_SND_BUF/TCP_MSS)
#define TCP_SND_QUEUELEN        (2* TCP_SND_BUF/TCP_MSS)
// Максимальный размер окна (в байтах) для приема данных. Рекомендуется использовать такой же размер окна
// как в автоподстановке TCP_SND_BUF
#define TCP_WND                 (8*TCP_MSS)
Очень сомневаюсь я в правильности понимания настроек MEMP_NUM_TCP_SEG, TCP_SND_BUF и TCP_SND_QUEUELEN.
Я так понимаю, что для моей проблемы актуальна настройка TCP_QUEUE_OOSEQ, которую надо установить в 1. На самом деле разницы нет. Пакеты теряются.
У меня принципиальное непонимание: вот я вызываю функцию netconn_write(), она всегда возвращает 0. Даже когда клиент "висит" и не принимает данные.
Какой то ведь флаг должен установиться, когда переполняется область TCP_SND_BUF? Заранее спасибо всем, кто захочет помочь.
Pasha_Bi вне форума   Ответить с цитированием
Старый 07.03.2017, 11:41   #2
Рак
Senior Member
 
Регистрация: 02.04.2008
Адрес: Кременчуг
Возраст: 31
Сообщений: 1,268
Вес репутации: 2175/67
Рак 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: Конфигурация LwIP стека

Думаю, нужно "допиливать" прием данных. К тому же, отправка подтверждения на принятый пакет - это не дело приложения, а немного глубже в ОС. Приложению маякнули, что принято, а что с этим делать уже дело пользовательской программы.
Рак на форуме   Ответить с цитированием
Старый 07.03.2017, 21:58   #3
Pasha_Bi
Senior Member
 
Регистрация: 24.07.2009
Адрес: г. Иваново
Возраст: 42
Сообщений: 256
Вес репутации: 617/37
Pasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to allPasha_Bi is a name known to all
По умолчанию Re: Конфигурация LwIP стека

Спасибо. Да, дело в приложении. Сегодня убедился, что даже если в приложении вообще не читать данные из сокета, ACK пакеты отправляются (смотрел Wireshark). Опрашивать принятые данные в прерываниях таймера - неудачный подход. Выделил отдельный поток, назначил ему приоритет повыше. Сокет - в блокирующий режим (режим по умолчанию). Вроде не пропадают пакеты. Еще раз спасибо. А с настройками LwIP все равно не очень прозрачно у меня пока. Буду искать, эксперементировать (по возможности). Если разберусь, отпишусь в этой же теме.
Pasha_Bi вне форума   Ответить с цитированием
Ответ


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

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

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

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

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Снова проблема ожидания ACK в LwIP с другого боку. Petr Cетевые протоколы и технологии 9 30.12.2016 10:47
Android VS LwIP Petr Cетевые протоколы и технологии 96 29.12.2016 12:40
структура TCP/IP стека LwIP v1.3.2 Pridnya Cетевые протоколы и технологии 42 13.12.2016 15:26
C18 и размер програмного стека. Как померять? FlashBack Продукция MICROCHIP 11 09.07.2014 14:03
Как отследить момент переполнения стека 123ksn Вопросы начинающих 27 13.10.2012 00:36


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


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