Windows. Код работы по UDP взят из матлаб. В РС из прибора приходят данные. В сниффере видно, что данные идут стабильно. Программа на РС принимает эти приходящие данные. Иногда, при включении, данные принимаются, иногда нет. udpOpenSend(…),udpOpenReceive(…) всегда проходят успешно, а udpReceive(…), когда данные не идут, возвращает ERR_FIFO_EMPTY. Приём происходит в отдельном потоке и быстрее чем передача прибором. Если закрыть канал и заново открыть его, без выхода из программы, данные могут начать приниматься, а могут и не приниматься. Как стабилизировать работу UDP?

Ну во первых UDP и есть не стабильный протокол.
А во вторых мониторь  время отвправки пакетов и время когда идет попытка на чтения(Какой промежуток??? и подумай...)

«Ну во первых UDP и есть не стабильный протокол.» - это понятно, но не до такой же степени!
«Приём происходит в отдельном потоке и быстрее чем передача прибором.» Отсылка данных прибором идёт с периодом 100 мс, попытка приёма с периодом 1 мс. Как я понимаю, и в этом я могу ошибаться, хотя бы через 100 циклов попыток приёма данные в буфере должны появиться, именно так и происходит когда с приёмом всё нормально. Ещё одно наблюдение, если прибор включить после запуска программы, то сбоев не происходит. Прибор получает команды из программы всегда, без сбоев.

Значит коннект где то валится.....


У вас вопрос на подобии "у меня программа не работает, я все проверил но не работает что делать??? ОС переустановить??? Компилятор поменять??? "

коннект? у UDP?  

«У вас вопрос на подобии "у меня программа не работает,…» да не на подобии вопрос. Надежда на то, что у кого-нибудь были такие же проблемы и товарищ поделится опытом. Большое дело ОПЫТ!!!
Складывается впечатление, что дело в моменте открытия сокета или первой попытке чтения.

Использовать TCP.

Зачем вам циклиться с 1 мс?
Делаете обычный блокирующий UDP сокет - выходите на recvfrom() - и висите на нем до того как прийдет полный UDP-пакет.
И никаких проблем.......

Посмотрел код. Есть там функция recvfrom(), но программа выходит раньше по проверке
if (mes == 0)
    return ERR_FIFO_EMPTY;

 

Стивенс пишет, что для  FIONREAD указатель должен быть обязательно на int
У вас же:
unsigned long mes = 0;
Может в этом фишка?
Ну и затем.....если у вас 0, вы вообще возвращаетесь.....
Ладно, ведь данных может и не быть, тем более что UDP-пакет должен прибыть полностью - иначе событие не взведется....
Значит, надо возвращаться через таймаут на повторное ожидание - и тд.
Это у вас и есть милисекундный цикл?
Т.е. я так думаю, что это ведь не TCP- когда у него прийдет хоть один байт - уже нормально.
В UDP - должен прийти весь пакет.
Какой длины у вас может быть пакет?
Тут что-то не стыкуется по логике.....
Я предлагаю вообще выкинуть ioctl - и висеть на recvfrom - cразу......сколько надо.......
можно select' ом сделать таймаут.......

Это сообщение отредактировал(а) Олег2005 - 19.10.2009, 14:44

Я пробовал убрать ioctlsocket. Висит в recvfrom и не выходит.
 
В MSDN-е этот аргумент дан как u_long. По другому компилятор (Visual Studio 2008) ругается.
 
Да, он самый.

В сниффере видно, что пакеты идут всегда и полностью, длина пакета 44 байта. Принимает или нет программа эти пакеты, PC ICMP запросы не шлёт. Получается, что программа UDP пакеты вычитывает из буфера?

Именно до такой)

По всему сказанному, остается дополнить: http://www.rsdn.ru/article/unix/sockets.xml

Итак, еще пара вопросов.
Шлет у вас пакеты - некое железо (прибор)
Может он шлет - ооооочень быстро? Быстрый передатчик UDP может забить медленный приемник.
Во всяком случае надо это иметь в виду.
Далее - не приходит вообще НИ ОДИН пакет? В принципе?
Насчет recvfrom()
Суть ее в том, что она просто копирует из приемного буфера сокета в модуле UDP(cистемного буфера) в буфер приема, указанный в параметрах функции. Операция копирования в буфер разрешается системой только тогда, когда прийдет весь UDP-пакет.
Потому recvfrom и ждет всего пакета.


Что то я не понял сути фразы вычитает - или считывает?
Далее
(udp[udpDesc].sock, (char *) what, length, 0, (LPSOCKADDR) & udp[udpDesc].sockFrom, &len)
У вас достаточно сложная система параметров - а нет ли в ней ошибки - просто указываете не на тот сокет, не на тот адрес, не ту длину (обычно рекомендуют применятьsizeof())
Надо бы в дебаге посмотреть значение параметров.....

Прибор шлёт с периодом 100 мс, приём идёт с периодом 1 мс.


Увы, но именно так. Это тогда, когда приёма нет. Программа висит в функции recvfrom(), если я закрываю вызов функции ioctlsocket().


Как я понимаю ICMP запросы PC посылает тогда, когда программа, которая должна принимать данныеБ посланные на этот PC, не работает. Именно это я наблюдаю в сниффере, программа не работает, ICMP запросы идут, запускаю программу, запросы прекращаются. И это не зависимо от того принимает программа данные или нет.


Код не мой, взят из матлаб. Длина берётся как sizeof(), только это делается при вызове функции udpReceive().
Я сейчас закрыл все другие действия в программе. Она работает только на чтение с одного канала.


Проверил. Меняется только значение сокета udp[udpDesc].sock. Но это понятно, оно меняется когда я, по кнопке, закрываю каналы и вновь их открываю. По любому по этим значениям данные могут приниматься и не приниматься.

Этого я не понял......

ICMP - наверно не запросы  а сообщения об ошибке - destination unreachable
Как только вы запускаете программу на каком либо порту, пункт назначения становится достижимым.....


Прокомментируйте мне ваши проверки - и покажите, как вы заполняете структуры адресов сокетов - программы(получателя данных) и прибора
С прибора вы ведь получаете данные - и ему тоже что-то отправляете?

А вообще выложили бы весь код - приаттачили.......

Это сообщение отредактировал(а) Олег2005 - 20.10.2009, 16:18