UDP передача слишком быстрая, Apache Mina не справляется
Мы решили использовать UDP для отправки большого количества данных, таких как координаты между:
- клиент [C ++] (используя опрос)
- сервер [JAVA] [Apache MINA]
Мои дейтаграммы имеют максимум 512 байт, чтобы избежать фрагментации во время передачи.
Каждая датаграмма имеет добавленный мной заголовок (с внутренним идентификатором), чтобы я мог отслеживать:
- сколько дейтаграмм получено
- какие из них получены
Проблема в том, что мы отправляем датаграммы слишком быстро. Мы получаем, как первые, и затем получаем большие потери, а затем снова и снова большие потери. Последовательность полученных дейтаграмм ID является чем-то вроде [1], [2], [250], [251] …..
Проблема возникает и в локальной сети (с использованием localhost, только 1 сетевая карта)
Я не забочусь о потере дейтаграмм, но здесь речь идет не о простой потере из-за сети (с которой я могу иметь дело)
Итак, мои вопросы здесь:
- На клиенте, как я могу получить лучшее:
- настройки или настройки сокета?
- способ отправить столько, сколько я могу, не будучи много?
- На сервере Apache MINA, кажется, говорит, что он сам управляет ~ «размером буферного сокета» ~, но есть ли еще какие-то настройки, о которых нужно позаботиться?
- Можно ли достичь чего-то вроде 1 МБ / с, зная, что наше соединение уже позволяет нам иметь хотя бы такую пропускную способность при загрузке обычных файлов?
В настоящее время, когда мы хотим передать информацию о координатах ~ 4 КБ, нам нужно добавить время ожидания, чтобы мы ждали 5 или более минут, чтобы завершить его, для нас это большая проблема, зная, что мы должны отправлять каждую минуту не менее 10 МБ. координаты информации.
Решение
Если вы хотите надежный транспорт, вы должны использовать TCP. Это позволит вам отправить почти так же быстро, как медленнее сети и клиента, без потерь.
Если вы хотите высоко оптимизированный транспорт с низкой задержкой, который делает не должен быть надежным, вам нужен UDP. Это позволит вам отправлять сообщения с той же скоростью, с какой может справиться сеть, но вы также можете отправлять быстрее или быстрее, чем клиент может прочитать, и тогда вы потеряете пакеты.
Если вам нужен надежный высокооптимизированный транспорт с малой задержкой и детализированным управлением, вы в конечном итоге будете реализовывать пользовательское подмножество TCP поверх UDP. Это не похоже на то, что вы могли или должны сделать это.
… как я могу получить лучшие настройки или настройки сокета
Как правило, экспериментально.
Если причина, по которой вы теряете пакеты, заключается в том, что клиент работает медленно, вам нужно сделать клиент быстрее. Большие приемные буферы покупают только фиксированное количество запаса (скажем, для поглощения пакетов), но если вы систематически медленнее, то любой буфер разумного размера в конце концов заполнится.
Тем не менее, обратите внимание, что это только излечивает чрезмерные или предотвращаемые падения. Различным слоям сетевого стека (даже не выходя из одного блока) разрешено отбрасывать пакеты, даже если ваш клиент может не отставать, поэтому вы все равно не можете считать его надежным без настраиваемой логики повторной передачи (и мы вернулись к реализации TCP) ,
… способ отправить столько, сколько я могу, не будучи много?
Вам нужно какое-то ack / nack / противодавление / удушение / перегрузка / любое сообщение от получателя обратно к источнику. Это именно то, что TCP предоставляет вам бесплатно, и что довольно сложно реализовать самостоятельно.
Можно ли достичь что-то вроде 1 МБ / с …
Я только что видел 8 МБ / с, используя scp over loopback, поэтому я бы сказал, да. Он использует TCP и, очевидно, выбрал AES128 для шифрования и дешифрования файла на лету — это должно быть тривиально, чтобы получить эквивалентную производительность, если вы просто отправляете открытый текст.
Другие решения
UDP является жизнеспособным выбором только тогда, когда любое количество дейтаграмм может быть потеряно без ущерба для QoS. Я не знаком с Apache MINA, но описанный сценарий напоминает сервер, который последовательно обрабатывает каждую дейтаграмму. В этом случае все дейтаграммы, поступившие во время обслуживания, будут потеряны — нет очереди дейтаграмм UDP. Как я уже сказал, я не знаю, можно ли настроить MINA для параллельной обработки дейтаграмм, но если это невозможно, это просто неправильный выбор инструментов.