|
|
  |
Вышла предварительная версия TN NET TCP/IP stack |
|
|
|
Oct 15 2010, 11:17
|
Частый гость
 
Группа: Участник
Сообщений: 180
Регистрация: 5-04-09
Пользователь №: 47 205

|
QUOTE (yuri_t @ Oct 14 2010, 17:50)  Каждое ТСР соединение требует приличного (опять-таки, для прс с малым кол-вом ОЗУ) объема ОЗУ для внутренних нужд. Как здесь справедливо заметили - не так уж и много нужно. В 32к таких мелких сокетов можно изрядно наплодить. QUOTE (yuri_t @ Oct 14 2010, 17:50)  Если надо принимать/передавать малые объемы данных и не часто, то ТСР не нужен - UDP прекрасно справится. Именно так и думал. Но админы всяких VPN/проксей/файрволлов/и т.д. думают иначе, в результате чего UDP трафик цинично рубят на корню.
Сообщение отредактировал LightElf - Oct 15 2010, 11:18
|
|
|
|
|
Oct 17 2010, 06:01
|
Частый гость
 
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937

|
Чтобы иметь возможность неблокирующего приема в TN NET TCP, достаточно в файле tn_tcp_sockets.c (TN NET v.0.9) добавить после линии 566 следующее выражение Код if(so->so_state & SS_NBIO) //-- For non-blocking socket - exit return -EWOULDBLOCK; Было: Код if(m) break; else { splx(tnet, sm); tn_net_wait(&so->so_rcv.sb_sem); } Стало: Код if(m) break; else { splx(tnet, sm);
if(so->so_state & SS_NBIO) //-- For non-blocking socket - exit return -EWOULDBLOCK;
tn_net_wait(&so->so_rcv.sb_sem); } Все другие части TCP(в том числе и tcp_s_send() ) уже готовы для работы в неблокирующем режиме SS_NBIO.
|
|
|
|
|
Nov 16 2010, 15:36
|
Группа: Участник
Сообщений: 12
Регистрация: 30-01-08
Пользователь №: 34 586

|
Прошу прощения,может есть такие,у кого есть опыт использования DP83848 в качестве PHY в TN NET?
Сообщение отредактировал AntonPV - Nov 16 2010, 16:05
|
|
|
|
|
Dec 27 2010, 02:42
|

Местный
  
Группа: Свой
Сообщений: 211
Регистрация: 3-06-06
Пользователь №: 17 742

|
Я попытался портировать стек на процессор LPC1768, но до конца он так и не заработал. Может быть у кого-нибудь был подобный опыт? Свой проект выложил в соседней ветке: http://electronix.ru/forum/index.php?showtopic=84637Наверняка мелочь какая-нибудь осталась, но сил больше нет
--------------------
Good News Everyone!
|
|
|
|
|
Dec 27 2010, 11:26
|
Участник

Группа: Участник
Сообщений: 59
Регистрация: 3-01-07
Из: Germany
Пользователь №: 24 071

|
Да, выложил в указанном топике. В tn_net_cfg.h #define USE_PHY_KS8721 или #define USE_PHY_DP83848C выбрать.
|
|
|
|
|
Feb 1 2011, 18:47
|

Странник
   
Группа: Свой
Сообщений: 766
Регистрация: 29-08-05
Из: Екатеринбург
Пользователь №: 8 051

|
Ошибочка обнаружена в проверке на multicast, не работали адреса xx.xx.xx. 224 - xx.xx.xx. 239 (пинг проходит, а соединение не устанавливается) Код Index: tn_tcp_input.c =================================================================== @@ -309,7 +309,7 @@ th = (struct tcphdr *)(((unsigned char *)m->m_data) + iphlen); tlen = m->m_tlen - iphlen; //-- TCP header + data - if(IN_MULTICAST(ip->ip_dst.s__addr) || in_broadcast(ip->ip_dst, ni)) + if(IN_MULTICAST(ntohl(ip->ip_dst.s__addr)) || in_broadcast(ip->ip_dst, ni)) goto drop; if(in4_cksum(m, IPPROTO_TCP, iphlen, tlen)) @@ -492,7 +492,7 @@ //-- packet with M_BCAST not set. if(m->m_flags & (M_BCAST|M_MCAST) || - IN_MULTICAST(ip->ip_dst.s__addr)) + IN_MULTICAST(ntohl(ip->ip_dst.s__addr))) goto drop; //---- Digest of the in_pcbconnect() for tcp_input() @@ -1205,7 +1205,7 @@ //-- Don't bother to respond if destination was broadcast/multicast. if((tiflags & TH_RST) || m->m_flags & (M_BCAST|M_MCAST) || - IN_MULTICAST(ip->ip_dst.s__addr)) + IN_MULTICAST(ntohl(ip->ip_dst.s__addr))) goto drop; if(tiflags & TH_ACK)
--------------------
"Как много есть на свете вещей, которые мне не нужны!" Сократ
|
|
|
|
|
Feb 2 2011, 15:30
|
Частый гость
 
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937

|
Цитата(spf @ Feb 1 2011, 22:47)  Ошибочка обнаружена в проверке на multicast, не работали адреса xx.xx.xx.224 - xx.xx.xx.239 (пинг проходит, а соединение не устанавливается) Спасибо!
|
|
|
|
|
Jul 30 2013, 14:17
|

Профессионал
    
Группа: Свой
Сообщений: 1 080
Регистрация: 16-11-04
Из: СПб
Пользователь №: 1 143

|
Цитата(spf @ Feb 3 2011, 08:28)  Когда ожидается вариант со всеми доработками? Кстати, какие замечены косяки ? я нашел только про tcp_respond CRCСам же я напоролся на следующий косяк, в функции arp_request не инициализируется MAC отправителя нужно после bcopy((unsigned char *)etherbroadcastaddr, (unsigned char *)eh->ether_dhost, MAC_SIZE); добавить bcopy((unsigned char *)ni->hw_addr, (unsigned char *)eh->ether_shost, MAC_SIZE); ну и еще мелочь:автор задал такой вид конфигурирования #define TN_DHCP 1 подразумевая что выключатся будет через #define TN_DHCP 0 то в местах применения писать не #ifdef TN_DHCP а #if TN_DHCP == 1
--------------------
Марс - единственная планета, полностью населенная роботами (около 7 штук).
|
|
|
|
|
Jul 31 2013, 03:25
|

Профессионал
    
Группа: Свой
Сообщений: 1 080
Регистрация: 16-11-04
Из: СПб
Пользователь №: 1 143

|
Цитата(megajohn @ Jul 30 2013, 18:17)  Сам же я напоролся на следующий косяк, в функции arp_request не инициализируется MAC отправителя Оказывается, об этом было известно еще три года назад, и напоролся на это Bender. Извиняюсь на непреднамеренный плагиат, то вчера весь день убил на поиск этой траблы Я то думал, что скачивал самую последнюю версию с сайта с фиксами. А оказалось что казалось.
--------------------
Марс - единственная планета, полностью населенная роботами (около 7 штук).
|
|
|
|
|
Aug 6 2013, 15:32
|

Профессионал
    
Группа: Свой
Сообщений: 1 080
Регистрация: 16-11-04
Из: СПб
Пользователь №: 1 143

|
Цитата(yuri_t @ Sep 22 2010, 15:33)  Поэтому большая просьба ко всем пользователям TN NET - пишите, пожалуйста, обо всех проблемах и найденных багах(в любой форме - через e-mail конференции, на e-mail yuri at tnkernel.com, задавая вопросы в конференции etc.) . №1 IAR ARM 6.6 ругается на невыровненное обращение Warning[Pa039]: use of address of unaligned structure member I:\projects\_lib\protocol\ip\tn_net\in4_cksum.c 123 u.ipov.ih_src = mtod(m, struct ip *)->ip_src; u.ipov.ih_dst = mtod(m, struct ip *)->ip_dst; №2 в функции udp_s_recvfrom не особо нравится поведение, если пришло данных больше чем запрашивалось. к примеру нужно только 16 байт, а пришло 128. Записать только 16 и вернуть результат 16. ( по крайней мере в NDK для TI SYS/BIOS вроде так ) №3 udp_s_sendto блокирующая отправка работает если только нет пулов памяти. А пулов больше чем передающих дескрипторов, а в очередь передачи отправка размещается с полингом. а не блокировкой. Получается что задача которая все время отправялет UDP не дает процессорного времени всем более низкоприоритетным задачам. А лучше бы на момент отправки и реальной передачи блокировалась задача. Вроде так
--------------------
Марс - единственная планета, полностью населенная роботами (около 7 штук).
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|