| |
|
  |
 Вышла предварительная версия TN NET TCP/IP stack |
|
|
|
|
 Aug 13 2009, 14:50
|
Частый гость
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937
|
- по поводу портирования BSD
Идея была использовать BSD stack по максимуму, добавляя/изменяя только те части, которые не помещаются в 32kbyte RAM/128 kbyte ROM.
В частности, весь TCP/UDP/IP/ARP взят с минимальными изменениями из BSD Lite 4.4/OpenBSD/NetBSD. Изменения коснулись тех мест, которые не требуются и/или не помещаются в MCU типа LPCxx (например, не требуется перехода из kernel space в user space и обратно)
BTW, TCP stack будет выложен в ближайшее время.
IMHO, написать stack c нуля (начитавшись разнообразных RFC) конечно можно, но такой продукт, во-первых, будет
ничем не лучше BSD, во-вторых, потребует многолетнего тестирования для выявления всяких obscure bugs. Кстати,
такими проблемами страдают многие коммерческие реализации TCP/IP именно из-за ограниченной для маленьких
компаний возможности тестирования.
С другой стороны, если не устраивать революций в BSD Lite 4.4 TCP/IP, a изменить только незначительные/
второстепенные части, то можно всего за несколько итераций получить надежно работающий stack. Так поступила,
например, компания InterNiche в своем продукте NicheLite (и Microsoft (!) в WinSock2)
|
|
|
|
|
|
|
|
Aug 13 2009, 15:18
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(yuri_t @ Aug 13 2009, 16:50)  IMHO, написать stack c нуля (начитавшись разнообразных RFC) конечно можно, но.... Ну я к этому и не призывал  . Цитата С другой стороны, если не устраивать революций в BSD Lite 4.4 TCP/IP, a.... Вот именно этот путь мне очень привлекателен.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Mar 28 2010, 19:22
|
Группа: Участник
Сообщений: 3
Регистрация: 13-11-09
Пользователь №: 53 607
|
Цитата(yuri_t @ Oct 1 2009, 14:24) Вышла версии 0.9 TN NET TCP/IP stack.
Добавлен DHCP client.
Просьба ко всем, кто использует (пробует) TN NET TCP/IP stack - присылайте,
пожалуйста, ваши замечания и предложения на yuri@tnkernel.com. Здравствуйте Юрий. Пытаюсь использовать Ваш TCP/IP stack с TN kernel в одном проекте и столкнулся с такой проблемой. Есть задача, которая с одной стороны работает с клиентом на host PC по tcp/ip, а сдругой стороны с двумя очередями. Если задача читает сокет, то она естественно засыпает при отсутствии сообщений от клиента. Но тогда она может прозевать сообщение из очереди. Есть ли в Вашей реализации стека что-либо такое (типа select), что может сообщать о событии появления сообщения через сокет до вызова функции s_recv ?
Сообщение отредактировал sim732 - Mar 28 2010, 19:24
|
|
|
|
|
|
|
|
Mar 30 2010, 20:02
|
Группа: Участник
Сообщений: 3
Регистрация: 13-11-09
Пользователь №: 53 607
|
Почитал tn-net-sockets.pdf. Оказывается в Вашей реализации сокет можно перевести
в неблокирующий режим. Не очень хорошее решение моей проблемы (напрасно будет тратится
процессорное время), но все же лучше, чем ничего. Использую предоставленную функцию s_ioctl().
Сокет переводиться в неблокирующий режим не хочет. Смотрю исходные тексты и вижу, что
в функции tcp_s_recv() проверка состояния so->so_state на SS_NBIO вообще отсутствует. Т.е. в этой
версии tcp/ip стека(0.9) перевести открытый сокет в неблокирующее состояние нельзя.
|
|
|
|
|
|
|
|
Mar 31 2010, 18:00
|
Частый гость
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937
|
Ф-ция '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 например). При этом блокирующий прием работает естественным образом, а неблокирующий прием не нужен вообще (поэтому он и не реализован). Код void task_rx_socket_A_func(void * par)
{
for(;;)
{
rc = s_recv(g_s, (unsigned char*)g_rx_buf, RX_BUF_SIZE, 0);
if(rc < 0) //-- SOCKET_ERROR
{
}
else if(rc == 0) // closed by peer
{
}
else //-- got some data
{
//--processing data, obtained by the s_recv(), or send it to another task
}
//-----
}
}
|
|
|
|
|
|
|
|
Apr 1 2010, 08:39
|
Группа: Участник
Сообщений: 3
Регистрация: 13-11-09
Пользователь №: 53 607
|
Цитата(yuri_t @ Mar 31 2010, 21:00) В случае TNKernel/TN NET и использовании TCP sockets, task, в которой производится s_recv(), должна
только принимать по s_recv() и не в коем случае не ждать какие-то другие события, очереди etc.
Другие события, очереди etc. дожны ждать ДРУГИЕ task(s).
Результат приема должен посылаться в ДРУГУЮ task (c помощью tn_queue например).
При этом блокирующий прием работает естественным образом, а неблокирующий прием
не нужен вообще (поэтому он и не реализован). Спасибо Юрий за комментарий. Я так и поступил. Хотя и добавил пару строк в tn_tcp_send.c для того, чтобы было соответствие с документацией. Код if(m)
break;
else
{
if(so->so_state & SS_NBIO)
{
splx(tnet, sm);
return -EWOULDBLOCK;
}
else
{
splx(tnet, sm);
tn_net_wait(&so->so_rcv.sb_sem);
}
} Спасибо еще раз за Вашу работу. Отличная RTOS и стиль написания очень ясный.
|
|
|
|
|
|
|
|
May 25 2010, 09:27
|
Частый гость
Группа: Участник
Сообщений: 180
Регистрация: 5-04-09
Пользователь №: 47 205
|
Изучаю сорцы. Возникли несколько вопросов: 1) Можно ли вызывать s_send и s_recv одновременно из разных потоков для одного и того же сокета? То есть один поток ждет прихода данных из сокета, а второй - в сокет пишет. 2) Может в силу лености ума не очень понимаю взаимодействие стека с ethernet контроллером. Нет ли какого-нибудь porting guide или это с моей стороны совсем уж наглость ? 3) Правильно ли я понимаю, что в порте TNKernel под Coldfire прерывания обрабатываются на стеке текущего процесса?
|
|
|
|
|
|
|
|
May 25 2010, 17:59
|
Частый гость
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937
|
Цитата(LightElf @ May 25 2010, 12:27) Изучаю сорцы. Возникли несколько вопросов:
1) Можно ли вызывать s_send и s_recv одновременно из разных потоков для одного и того же сокета? То есть один поток ждет прихода данных из сокета, а второй - в сокет пишет. Можно Цитата 2) Может в силу лености ума не очень понимаю взаимодействие стека с ethernet контроллером. Нет ли какого-нибудь porting guide или это с моей стороны совсем уж наглость ? На какой процессор собрались портировать ?
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
