Имеет ли смысл иметь более одного сокета UDP Datagram в режиме ожидания? «Одновременные» пакеты отбрасываются или помещаются в очередь ядром?

Question

Я пишу сетевое приложение на Android.

Я имею в виду наличие одного порта UDP и сокета дейтаграмм, который получает все датаграммы, которые отправляются на него, а затем имеют разные очереди обработки для этих сообщений.

Я сомневаюсь, что у меня должен быть второй или третий сокет UDP в режиме ожидания. Некоторые сообщения будут очень короткими (100 байт или около того), но другим придется передавать файлы.

Меня беспокоит, будет ли ядро ​​Android отбрасывать маленькие сообщения, если оно слишком занято обработкой больших?

Обновление «Последняя функция вызывает sock_queue_rcv_skb () (в sock.h), которая ставит в очередь пакет UDP в приемном буфере сокета. Если в буфере больше не осталось места, пакет отбрасывается. выполняется этой функцией, которая вызывает sk_filter () точно так же, как и TCP. Наконец, вызывается data_ready (), и прием пакетов UDP завершается. "

Answer 1

Давайте сначала разберемся с некоторыми основами:

Каждый сокет имеет буфер приема и отправки. Когда сетевое оборудование сообщает о прибытии нового пакета и , приемный буфер заполнен, пакет отбрасывается. Размеры буфера контролируются с помощью опций сокетов SO_RCVBUF и SO_SNDBUF, см. setsockopt(3). ОС устанавливает некоторые значения по умолчанию (и есть файл /etc/sysctl.conf). Это в системе BSD:

~$ sysctl -a|grep space
net.inet.tcp.recvspace=16384
net.inet.tcp.sendspace=16384
net.inet.udp.recvspace=41600
net.inet.udp.sendspace=9216

Разница между TCP и UDP заключается в том, что первый обеспечивает упорядочение данных и повторную передачу отброшенных пакетов, а также управление потоком (медленное чтение замедляет быструю запись), в то время как последний не делает.

Так что да, использование UDP для передачи файлов - не лучший вариант, , но работоспособный , вариант. Нужно просто заново изобрести часть TCP и сравнить издержки этого изобретения с TCP. С другой стороны, общая мудрость заключается в том, что UDP лучше всего подходит для приложений, которые могут допустить переупорядочение / потерю некоторых пакетов (например, потоков аудио / видео).

Тогда существует ошибочное мнение, что каждому сокету нужен отдельный поток для отправки / получения данных, что далеко от истины. Многие превосходные высокопроизводительные сетевые приложения были написаны без потоков, но с использованием неблокирующих сокетов и некоторого механизма опроса (см. select(2), poll(2), epoll(7)).

К самому вопросу:

Да, ядро ​​может отбрасывать пакеты, если приложение слишком занято, чтобы хранить достаточно свободного места в приемных буферах сокетов. Но так как каждый сокет имеет свой собственный, разделение потоков управления и данных поможет. Лично я хотел бы выполнить простую настройку TCP-сервера - прослушивать порт, принимать соединение для каждого клиента, реализовывать значимый протокол поверх потока TCP. Я согласен с тем, что играть с UDP-машинами и конечными автоматами низкого уровня очень весело, но это уже сделано, и десятилетия исследований были направлены на настройку производительности TCP. В конечном итоге важна надежность (во-первых) и производительность (во-вторых) вашего приложения.

Надеюсь, это поможет.

Answer 2

UDP - плохая идея для передачи файлов, так как вы не можете гарантировать порядок, в котором будут приниматься пакеты, или вообще будут ли они приниматься. Если вы хотите создать отказоустойчивый транспортный уровень поверх этого, вам следует просто использовать вместо него TCP / IP, поскольку это именно то, что он делает.

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

Я не понимаю, как открытие дополнительных портов вам сильно поможет. Если вы заняты обработкой пакета с порта 1, то вы пропустите любые пакеты, поступающие на любые другие порты, которые вы просматриваете, если только они не работают в выделенном потоке. Вам было бы гораздо лучше быстро скопировать пакет в свой собственный буфер и передать его другому потоку для его обработки, чтобы ваш поток слушателя мог вернуться к прослушиванию как можно скорее.

Answer 3

Контроль потока TCP поможет вам уменьшить количество пропущенных пакетов. Он отказоустойчив и гарантирует, что пакет будет доставлен в последовательности.