[Sagittarius 0]

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

 

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

 

Спасибо.

[kolobok0 0]

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

 

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

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

 

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

 

 

(круглый)

[scifi 1]

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

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

[kolobok0 0]

Там бывает буферизация...

 

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

 

 

(круглый)

ЗЫ

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

 

[Segment 3]

А какая разница — потеряли пакет в стеке или в сети? Без подтверждения доставки это одно и то же.

[Arlleex 131]

вот это в правильной реализации не должно быть по определению...

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

 

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

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

Изменено 5 августа, 2018 пользователем Arlleex

[kolobok0 0]

...По 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 (по описанию)...

 

как то так

(круглый)

 

[TU-104 0]

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

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

Буфер один, а в 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

Изменено 7 августа, 2018 пользователем TU-104

[Sagittarius 0]

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

 

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

 

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

 

Спасибо.