| |
|
  |
 Вышла предварительная версия TN NET TCP/IP stack |
|
|
|
|
 Oct 13 2010, 10:38
|
Частый гость
Группа: Участник
Сообщений: 123
Регистрация: 28-06-05
Из: Тула
Пользователь №: 6 361
|
Цитата(yuri_t @ Mar 31 2010, 22:00)  Ф-ция 'select' создавалась для классических аппликаций - где нет multithreading и все происходит
внутри одной ф-ции main(). Для малоформатных RTOS типа TNKernel 'select' "тяжеловат", да и в
общем-то и не нужен (IMHO).
В случае TNKernel/TN NET и использовании TCP sockets, task, в которой производится s_recv(), должна
только принимать по s_recv() и не в коем случае не ждать какие-то другие события, очереди etc.
Другие события, очереди etc. дожны ждать ДРУГИЕ task(s).
Результат приема должен посылаться в ДРУГУЮ task (c помощью tn_queue например).
При этом блокирующий прием работает естественным образом, а неблокирующий прием
не нужен вообще (поэтому он и не реализован). Мне нужно принимать данные по TCP от нескольких устройств (>10), интервалы посылок разные. Придется создавать задачи по количеству устройств, выделять буфера и стеки под них - некрасиво. ИМХО применив неблокирющий прием можно обойтись одной задачей.
|
|
|
|
|
|
|
|
Oct 13 2010, 10:55
|
Частый гость
Группа: Участник
Сообщений: 97
Регистрация: 2-01-09
Пользователь №: 42 891
|
Цитата(Bender @ Oct 13 2010, 14:38) Мне нужно принимать данные по TCP от нескольких устройств (>10), интервалы посылок разные. Придется создавать задачи по количеству устройств, выделять буфера и стеки под них - некрасиво. ИМХО применив неблокирющий прием можно обойтись одной задачей. Спрашивал у автора на эту тему в прошлом году, т.к. это позволяло в моем случае сэкономить пару задач и соответственно бесценной ОЗУ. Думаю, не сложно это самостоятельно реализовать.
Сообщение отредактировал grinux - Oct 13 2010, 10:56
|
|
|
|
|
|
|
|
Oct 13 2010, 16:44
|
Частый гость
Группа: Участник
Сообщений: 180
Регистрация: 5-04-09
Пользователь №: 47 205
|
QUOTE (yuri_t @ Oct 13 2010, 19:34) Работа с >10 одновременно открытых TCP connections - это, IMHO, в любом случае многовато для CPU с памятью ~32KB  Хм. А как связано количество одновременных соединений с объемом ОЗУ? Я почему-то думал, что вопрос скорее в объеме данных (и соответственно в размере и количестве буферов). Если изредка (раз в минуту например) передается по 10-20 байт, то почему бы и нет? ИМХО вполне типичная задача для всяческих датчиков и т.п.
|
|
|
|
|
|
|
|
Oct 13 2010, 18:52
|
Частый гость
Группа: Участник
Сообщений: 123
Регистрация: 28-06-05
Из: Тула
Пользователь №: 6 361
|
Цитата(LightElf @ Oct 13 2010, 20:44) Хм. А как связано количество одновременных соединений с объемом ОЗУ? Я почему-то думал, что вопрос скорее в объеме данных (и соответственно в размере и количестве буферов). Если изредка (раз в минуту например) передается по 10-20 байт, то почему бы и нет? ИМХО вполне типичная задача для всяческих датчиков и т.п. Да-да, именно так и есть, небольшие порции данных раз за 1-10 секунд
|
|
|
|
|
|
|
|
Oct 14 2010, 13:10
|
Частый гость
Группа: Участник
Сообщений: 180
Регистрация: 5-04-09
Пользователь №: 47 205
|
QUOTE (Bender @ Oct 13 2010, 22:52) Да-да, именно так и есть, небольшие порции данных раз за 1-10 секунд BTW, часто от изучения сорцов разных "мелких" TCP/IP стеков остается ощущение, что стеки оные заточены в первую голову на всякие HTTP и FTP серверы, а не на реальные применения. Типо "бутлодер с поддержкой HTTP PUT для обновления прошивки". Убил бы  Даже uIP на что мелкий, и то к делу приспособить не удалось из-за проблем с delayed acknowledge.
|
|
|
|
|
|
|
|
Oct 14 2010, 18:42
|
Частый гость
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937
|
Цитата(grinux @ Oct 14 2010, 18:49) Подскажите, как использовать новый MAC адрес без полной переинициализации стека?
C IP и прочим разобрался, - закрываю все сокеты, далее net_iface1_set_addresses().
Если там же менять MAC (ni->hw_adr) то ICMP и ARP продолжает работать, а все остальное нет. Честно говоря, никогда бы не подумал, что потребуется "на лету" менять MAC... Зачем это Вам нужно ? Цитата(Bender @ Oct 14 2010, 21:18) Хорошо, еще такой вопрос - прибор "отвалился" - что делать, ведь выйти по таймауту невозможно? вечное ожидание? Я не понял - Вы говорите о TCP соединении?
|
|
|
|
|
|
|
|
Oct 15 2010, 05:07
|
Частый гость
Группа: Участник
Сообщений: 123
Регистрация: 28-06-05
Из: Тула
Пользователь №: 6 361
|
Цитата(yuri_t @ Oct 14 2010, 22:42) Я не понял - Вы говорите о TCP соединении? да, о нем. Я конечно пока "чайник", до этого пользовался только UDP. Но вот что делать в случае, если все задачи уже ждут сообщений, и вот с одним из клиентом теряется связь. Нового клиента, вместо потерянного уже слушать некому. Так?
|
|
|
|
|
|
|
|
Oct 15 2010, 07:13
|
Частый гость
Группа: Участник
Сообщений: 97
Регистрация: 2-01-09
Пользователь №: 42 891
|
Цитата(yuri_t @ Oct 14 2010, 22:42) Честно говоря, никогда бы не подумал, что потребуется "на лету" менять MAC... Зачем это Вам нужно ? Объективной необходимости нет, но меню настройки устройства построено по принципу Apply и отдельно Save. Чтобы можно было откатить неправильно сделанные настройки, сделав Reset. Это конечно же нетрудно переделать, я же в основном хотел понять для себя, почему недостаточно на горячую заменить MAC адрес в ni->hw_adr и в SA регистрах? Он где то еще прописывается? Цитата(Bender @ Oct 15 2010, 09:07) да, о нем.
Я конечно пока "чайник", до этого пользовался только UDP.
Но вот что делать в случае, если все задачи уже ждут сообщений, и вот с одним из клиентом теряется связь. Нового клиента, вместо потерянного уже слушать некому.
Так? При потере связи s_recv возвратит ошибку (<0), поток разблокируется и позволит снова сконфигурироваться для повторного установления соединения.
Сообщение отредактировал grinux - Oct 15 2010, 07:14
|
|
|
|
|
|
|
|
Oct 15 2010, 08:02
|
Частый гость
Группа: Участник
Сообщений: 123
Регистрация: 28-06-05
Из: Тула
Пользователь №: 6 361
|
Цитата(grinux @ Oct 15 2010, 11:13) При потере связи s_recv возвратит ошибку (<0), поток разблокируется и позволит снова сконфигурироваться для повторного установления соединения. Точно так. только потребовалось установить флаг SO_KEEPALIVE, и s_recv возвращает ошибку (=0)
Сообщение отредактировал Bender - Oct 15 2010, 08:03
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
