LINUX.ORG.RU

Частота отправки данных в UDP

 , , ,


0

1

Всем привет!

Написал приложение (клиент-сервер (C++/Linux(Ubuntu))), использую для асинхронности epoll и неблокирующие сокеты. Аналогичное приложение на Windows, только там WinSock2 и IOCP для асинхронности. В общем никогда не думал, что столкнусь с таким багом: мне сообщений приходит или больше, или меньше, чем я их отослал.

Теперь подробнее: есть модуль, который разбивает большие объемы данных на более мелкие (по 1000 байт) и отсылает их в цикле (сервер), этот же модуль (на клиенте) склеивает данные и предоставляет пользователю готовое сообщение (например при отсылке картинки). Модуль работает нормально, тестировал без сетевой части. Как только начал передавать данные по сети - появились баги.

Долго не мог понять в чем дело, потом написал тест для сокетов: 2 UDP сокета в цикле отсылают данные друг-другу, а при обработке принятия данных на конкретный сокет - сделал ранее 2 переменные (int), обнулил их и делаю инкремент определенной переменной. Например: отсылаю 1000 раз на каждый сокет по 1024 байта. Тест провален. В результате переменные не равны 1000, а они меньше (в epoll) и больше (в IOCP) этого значения.

При чем: если поставить после каждой отсылки delay или cout/printf - все работает без сбоев!

В связи с этим вопрос: где может быть баг и какая максимальная частота отправки сообщений для UDP?

Спасибо!

rtfm UDP не гарантирует доставку пакетов. Это значит что пакет могут как не доставлятьс вообще, так и доставляться дубликаты. Их порядок тоеж никто не гарантирует.

invy ★★★★★
()

udp не герантирует доставку. Сколько будет потеряно зависит от загруженности узлов на пути пакета.

soomrack ★★★★
()
Ответ на: комментарий от soomrack

Ну не гарантирует, и что? У меня обратная связь есть, которая как раз и гарантирует доставку пакета. Протокол самописный. Вот почему в цикле такая лажа происходит? Не ставить же delay на каждой отправке?

alexlogvinenkoit
() автор топика
Ответ на: комментарий от alexlogvinenkoit

У меня обратная связь есть, которая как раз и гарантирует доставку пакета.

значит, твоя обратная связь куёвая? /кэп. Если уж твой самопальный протокол действительно гарантирует доставку, то он так же должен маскировать все возможные «баги» с отправкой.

Не ставить же delay на каждой отправке?

раз уж начал делать свой велосипед, то стоит ознаковиться вот с этим, и переизобрести всё что там ещё раз для своей обратной связи.

mashina ★★★★★
()
Ответ на: комментарий от alexlogvinenkoit

Могу предложить искать ошибку в самодельном протоколе. Чтобы доставка таки гарантировалась.

invy ★★★★★
()

то что меньше - это ладно
но откуда у тебя там да и где - больше то пакетов береться ?

сеть 100 или гигабитная ?
если у тебя передаче выше значения сети - то при переполнении буферов - пакеты будут просто теряться

ae1234 ★★
()
Ответ на: комментарий от ae1234

Сеть вообще localhost, пока что тестирую на одной машине. Сам не знаю, но больше только на Windows(IOCP), на Linux(epoll) пакетов меньше, да и работает лучше, например 100 пакетов приходит правильно, а вот 1000 - есть недосчет где-то в 10-50 пакетов.

alexlogvinenkoit
() автор топика
Ответ на: комментарий от mashina

А при чем тут протокол? Протокол действует как положено: получил сообщение - отослал ответ. Тут дело в том, что прием данных воспринимается как незавершенная операция, поэтому пока не придут все пакеты - не будет доставки. А если ставить delay - операция завершена, отчет о доставке есть, все как надо)

alexlogvinenkoit
() автор топика
Ответ на: комментарий от alexlogvinenkoit

А при чем тут протокол? Протокол действует как положено: получил сообщение - отослал ответ.

извиняюсь, конечно, за нескромный вопрос... но таки _повторную_ пересылку твой протокол делает пакетов которые не дошли?

mashina ★★★★★
()
Ответ на: комментарий от mashina

Повторная отсылка есть, как раз одна из причин разбивания данных на мелкие, чтобы потом, если затеряется пакет, не отсылать все, а только 1 пакет в 1000 байт

alexlogvinenkoit
() автор топика
Ответ на: комментарий от alexlogvinenkoit

Повторная отсылка есть,

отлично. Ну так вперёд смотрнеть что такое 'congestion control'

и какой, кстати, был смысл городить вот весь этот свой треш когда до тебя давно уже сделали TCP?

mashina ★★★★★
()
Ответ на: комментарий от mashina

Смысл тот, что TCP работает реально медленнее, из-за самого протокола. Плюс к этому в приложении будет часто connect/disconnect, на которые тоже тратится много времени. Поэтому UDP)

alexlogvinenkoit
() автор топика
Ответ на: комментарий от alexlogvinenkoit

Вот ты себе сейчас сделаешь 'congestion control' в своём протоколе и оно у тебя будет работать в лучшем случае примерно так же, как и TCP. А в наиболее вероятном случае вообще никак не заработает ещё несколько месяцев.

mashina ★★★★★
()
Ответ на: комментарий от mashina

анука плюсанука!

От себя добавлю: лучше заюзать onc rpc. Там всё просто до безобразия, и оверхед очень небольшой.

nanoolinux ★★★★
()
Ответ на: комментарий от alexlogvinenkoit

делать замену tcp - нужно лиш в одном случае
только тогда - когда скорость до оконечного получателя тебе известна - как и емкость буферов по дороге
если у тебя до получателя гигабит - то ты сможешь сразу на гигабите засунуть в сетевую пакетов - и они все дойдут
а tcp будет пытаться анализировать среду передачи - и раскачивать скорость

в других случаях - у тебя получиться что то подобное tcp но крайне недоделанное

ae1234 ★★
()
Ответ на: комментарий от invy

invy * писал:
«могут как не доставлятьс вообще, так и доставляться дубликаты».
Прошу ответить, кто знает, invy погорячился, или действительно
UDP может доставить дубликат?
Имею ввиду чистый UDP, без самодельных надстроек.

oleg_2
()
Ответ на: комментарий от alexlogvinenkoit

Смысл тот, что TCP работает реально медленнее, из-за самого протокола. Плюс к этому в приложении будет часто connect/disconnect, на которые тоже тратится много времени. Поэтому UDP)

Тогда стоит посмотреть на ZeroMQ.

gensym ★★
()
Ответ на: комментарий от gensym

Тогда стоит посмотреть на ZeroMQ.

причём тут оно то? Тоже использует TCP для сетевого транспорта, а для простого пула TCP соединений именно ZMQ не нужен, можно сделать проще.

mashina ★★★★★
()
Ответ на: комментарий от oleg_2

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

в остальном же: google://udp duplicate packets

invy ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.