Jump to content

    
Sign in to follow this  
Sagittarius

LwIP, UDP

Recommended Posts

Здравствуйте.

 

Проблемка, не могу найти как сдеалть. Микроконтроллер периодически (раз в 1с) посылает UDP пакет, все работает. Но надо за один раз посылать порядка 20 разных отдельных пакетов. Буфер для формирования пакетов один. Как определить что предыдущий пакет уже отправлен и можно формировать и отправлять следующий? Определить что именно отправлен, обработан модулем Eth и выдан в линию связи (а не принят адресатом).

 

Спасибо.

Share this post


Link to post
Share on other sites
...UDP пакет...Как определить что предыдущий пакет уже отправлен и можно формировать и отправлять следующий? Определить что именно отправлен, обработан модулем Eth и выдан в линию связи (а не принят адресатом)....

 

По определению.

Если изернет стэк это не делает - меняйте(правьте) нафик стэк.

 

UDP - гарантирует ОТПРАВКУ пакета. Т.е. если вам вернулось управление после вызова функции send - то пакет 200% ушёл в сеть.

 

 

(круглый)

Share this post


Link to post
Share on other sites
UDP - гарантирует ОТПРАВКУ пакета. Т.е. если вам вернулось управление после вызова функции send - то пакет 200% ушёл в сеть.

Там бывает буферизация, если ARP ещё не выяснил MAC. В общем, надо нырять в стек и смотреть. Самому сейчас лень.

Share this post


Link to post
Share on other sites
Там бывает буферизация...

 

вот это в правильной реализации не должно быть по определению. если мы отдали уже управление на вызове с уровня программы, забуфферизировали и успешно грохнулись(ну или не разрешился MAC адрес) - то это собственно нарушение контракта UDP интерфейса для юзверов.

 

 

(круглый)

ЗЫ

с ходу в рфс ничего конкретного не нашёл...может смотрел не дотошно - хз...

 

Share this post


Link to post
Share on other sites
вот это в правильной реализации не должно быть по определению...

Это с чего бы это не должно быть? Еще как должно быть, даже обязано быть. По UART когда отправляем, тоже данные буферизуем (по-хорошему). Чем Ethernet-то отличается? Тем более когда разговор о UDP. Если следовать Вашей логике, функция отправки не должна отдавать управление до тех пор, пока фрейм не будет отправлен. Тогда уж жуткие тормоза и околонулевая скорость потока гарантирована.

 

UDP - гарантирует ОТПРАВКУ пакета.

И ничего оно не гарантирует. Если места в буфере будет недостаточно - никакой отправки не произойдет, а если учесть, что разговор идет о LwIP, функция udp_sendto() вернет ошибку.

Edited by Arlleex

Share this post


Link to post
Share on other sites
...По UART когда отправляем...Чем Ethernet-то отличается? ...следовать Вашей логике...И ничего оно не гарантирует....вернет ошибку.

 

1) юарт - не определяет протокол, формат и взаимодействие по нему. Вы можете сами выбирать разрядность, чётность, и т.д.. А уж по формату фрэйма - вообще что угодно и как угодно.

UDP определён в конкретном документе. Если Вы изобразите нечто отличное от этого определения - то это уже будет не UDP...увы и ах... В этом собственно и отличие.

2) Это не моя логика. Это есть такая фигня как RFC768 (из разряда, а мужики то и не знали)...

3) В RFC написано... This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. Это из описания собственно. сэнд мэссэдж - собственно передача сообщения. ПЕРЕДАЧА. Не буфферезирование, а ПЕРЕДАЧА. Конечно-же можно как угодно трактовать слово "сенд".... но вот так вот написано само определение.

4) Про обработку ошибочных ситуаций не было речи - не теряйте фокус... Естественно речь идёт об успешном ответе при передачи UDP. Так вот, если стэк протокола ответит OK и при этом забуфферизирует данные и не разрешит MAC адресацию то собственно это уже будет не совсем UDP (по описанию)...

 

как то так

(круглый)

 

Share this post


Link to post
Share on other sites

Автор вообще пользу из этого пустого спора вынесет?

Буфер для формирования пакетов один.

Буфер один, а в LwIP же динамически память выделяется (в моем по крайней мере так) для каждого отправляемого/получаемого пакета

psend = pbuf_alloc(PBUF_TRANSPORT, UDP_ANS_MAX, PBUF_POOL);  // выделяем
pbuf_take(psend, UDP_ANS, UDP_ANS_MAX);  // copy data to pbuf 
udp_connect(upcb_echo, addr, port);//UDP_CLIENT_PORT_MON);  // отправляем на этот порт
[b]err = udp_send[/b](upcb_echo, psend); 
pbuf_free(psend);  // free pbuf /

а дальше

udp_sendto -> udp_sendto_if-> ip_output_if-> ip_output_if_opt-> (netif->output)

там уже где-то Low_level_output(..) где копируется в ДМА буфера.

Можно отследить эту ошибку "err =", но это только гарантия того, что данные передали для ОТПРАВКИ. А дальше они уже улетят так же (как говорили выше) как в UART

Edited by TU-104

Share this post


Link to post
Share on other sites
Автор вообще пользу из этого пустого спора вынесет?

 

автор забыл про отпуск перед написанием вопроса и ушел туда но уже вернулся :-)

 

Вопрос именно про конкретную реализацию а не про сферический в вакууме RFC. Что сейчас наблюдается: используя udp_sendto раз в секунду посылается 28 пакетов. Пробовал как подряд в цикле так и с паузой 20-200 мс. Но глюк один и тот же. Иногда последний пакет из пачки задерживается и приходит как первый при начале посылок за следующую секунду. Задержка именно в LwIP, смотрел траффик по Wireshark. Так что где то внутри буферизация есть и возврат из udp_send не означает физическую отправку пакета. Собственно вопрос тот же, как правильно отправлять последовательность пакетов по UDP используя LwIP?

 

Спасибо.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this