Плюсы и минусы одного порта на клиента? - PullRequest
2 голосов
/ 18 декабря 2011

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

Разве это не собственный код, чтобы убедиться, что содержимое этих буферов постоянно потребляется? На моем сервере я планирую делать это примерно 20-30 раз в секунду, и если мои клиенты отправляют пакеты с той же скоростью, я не вижу, как буферизация будет проблемой. FWIW, мои пакеты будут до 1024 байтов в длину. Я бы имел 4 или максимум 8 клиентов. Я понимаю из ряда источников (например, этот ответ ), что размер буфера по умолчанию в Windows составляет 8 КБ. Так что с 4 клиентами, это, как правило, должно быть хорошо, на мой взгляд ... хотя я предполагаю, что мне, возможно, нужно немного увеличить размер буфера, и я не уверен, есть ли какие-то подводные камни, хотя я знаю, что это сделано через setsockopt().

1 Ответ

0 голосов
/ 29 декабря 2011

Код, выполняющий буферизацию в ОС и на языке, является одинаковым независимо от порта, поэтому не имеет значения, входит ли он в несколько буферов в нескольких сокетах или в один буфер в одном сокете. Установка большего размера (N раз) буфера на одном сокете на одном порту будет эквивалентна N буферам на N портах.

Я бы также сказал, что если вы говорите о 8 * 30 пакетов в секунду (240 пакетов / сек), то, если вы не запускаете это на калькуляторе 1980-х, вам не нужно беспокоиться о производительности буферизации.

Если скорость отправки выше скорости чтения, тогда буфер будет заполнять и отбрасывать пакеты независимо от размера вашего буфера. Размер буфера будет просто указывать задержку.

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

Кроме того, поскольку иногда вы можете получить пакет с задержкой, который может быть объединен с одним или двумя другими маршрутизаторами по пути, я бы сказал, установите размер буфера чуть больше 8k (2x или 3x), чтобы вы не могли получить 3 пакета, которые были сгруппированы от одного клиента (2 из которых являются старыми, и вы будете отбрасывать или перезаписывать при чтении), перезаписывая свежие пакеты от некоторых других клиентов.

...