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

[alexlogvinenkoit]

Всем привет!

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

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

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

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

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

Спасибо!

[Yurror]

чувак, используй силу^W TCP
UDP ничего тебе не гарантирует. контроль целостности передачи исключительно на твоих плечах

да пожалуйста. для тебя только начинает открываться увлекательный мир сетей =)

[mkarasik]

Непонятно только как он больше получил Точно накосячил где то в коде.

[Yurror]

mkarasik,
фрагментация пакетов ничего странного
вариантов много

[mkarasik]

Фрагментация в UDP? Стирай скорее, пока кто нибудь не увидел. RAW сокеты входят в категорию накосячил.

[Yurror]

Да, каюсь, удп либо приходит либо умирает смертью храбрых. кусками не приходит.

[alexlogvinenkoit]

Вот везде слышу: "Используй TCP...".
Не подходит мне TCP, вот никак. И вообще: как могут теряться данные на localhost-е? Я еще могу понять при передаче данных через WiFi роутер... А при 127.0.0.1 - не должно вообще ничего теряться. Ну или я не прав и, действительно, слабо понимаю сетевое программирование... В этом случае попрошу у вас какие-то материалы (книги/статьи/туториалы) по сетям и асинхронной обработке (IOCP/epoll).
Спасибо!

[PetrovSE]

И вообще: как могут теряться данные на localhost-е

Запросто могут.

Сам долго мучался с этим, могу поделиться опытом.

Для начала желательно отправку и приёмку пакетов засунуть в отдельные нити, что бы никто их не задерживал.
В обеих нитях нужно завести очереди - в одну класть пакеты "на выход" из другой вынимать принятые.

Вот теперь важное.
При отправке нужно соблюдать временную дистанцию между пакетами в 100 - 500 микросек.
Если очередь начала сильно расти, то задержку уменьшаем, если уменьшается, то увеличиваем.

Ничего лучше я придумать не смог, однако оно не плохо работает.
Если есть какое-то радикальное решение, то буду рад услышать.

[mkarasik]

И вообще: как могут теряться данные на localhost-е

Запросто могут.

Сам долго мучался с этим, могу поделиться опытом....

Не нужно это читать. Нужно понимать, что делаешь, тогда ничего не будет теряться.

На локальном хосте данные могут теряться так же как и на удаленном. Достаточно чтобы отправитель посылал больше чем получатель может обработать. Речь о UDP. Поэтому является плохой практикой считать, что раз все локально, то все придет и не потеряется. Теряется еще как и в самый неподходящий момент. У протокола UDP  есть свое предназначение и использую его нужно четко осозноват, что данные могут и будут потерянны.

Вернемся к нашим баранам.

... отсылаю 1000 раз на каждый сокет по 1024 байта ...

Не помню сколько сейчас размер tx buffer (не знаю как русски, извиняюсь) в сокете, но думаю что 4К. Т.е. 4 пакета полностью забивают трансмит и еще 4 полностью забивают ресив и остальные начинают выбрасываться. Врядли отправка 8-ми пакетов происходит медленнее, чем происходит переключение процессов. В данном случае последствия не предсказуемые. Почему приходит больше до сих пор остается загадкой Чуствую, что без косяков в коде не обошлось.

Ну и напоследок, TCP идеально подходит для перекачивания даты из одного конца в другой, даже пакетизацию делать не нужно, тупо пиши в файл все, что прочитал.

Вот теперь важное.
При отправке нужно соблюдать временную дистанцию между пакетами в 100 - 500 микросек.
Если очередь начала сильно расти, то задержку уменьшаем, если уменьшается, то увеличиваем.

Люди сидели (ночами не спали) разрабатывали reliable connection oriented protocol with flow control, но *** нам нужно. Мы же тут все стратеги, хули нам 100500 функций вокруг UDP навалить с потоками и задержками.

При чем все равно потеряется дата в самый неподходящий момент, но главное же не дата, главное у нас

Ничего лучше я придумать не смог, однако оно не плохо работает.

Если есть какое-то радикальное решение, то буду рад услышать.

Ты не поверишь

Используй TCP

Пользователь решил продолжить мысль 12 Мая 2012, 17:43:49:

... Не подходит мне TCP, вот никак.

Ну звиняй хлопец, бананау у нас нема


___________________________
На Форуме ЗАПРЕЩЕНО
2.1. Использовать ненормативную лексику в любом виде. В том числе сокращённые и искажённые нецензурные слова. Замена нецензурных слов спецсимволами также не допускается.
grad-data

[victor00000]

udp пусто, у меня документ нету.

[Yurror]

udp пусто, у меня документ нету.

жеееесть.... после этого убивающего наповал аргумента наш ТС таки решился на переход на TCP
 

Ну акромя бананов есть еще SCTP =) забавная вещь.

используя SCTP/IPv6 можно почувствовать себя бета-тестеом интернета.

[mkarasik]

...
Ну акромя бананов есть еще SCTP =) забавная вещь.
...

Точно, блин. Старею, нового не замечаю. Спасибо за информацию, надо будет как нибудь попробовать.