Интересует сабжект. Ситуации такие:

1) есть серверная программа и клиентская которая симулирует 190 подключений к серваку.
каждый клиент шлёт 15 раз в секунду пакеты по 15 байт по udp, и принимает столько же от сервака.
при 190 клиентах трафик получается такой: 
 -входящий 0.3 Mb/s 
 -исходящий 0.3 Mb/s.

и проблема в том что всё ограничивается на 190 клиентах, если делать больше то пакеты с пингом от некоторых клиентов не доходят и их  выкидывает с сервака. предположение моё такое: тк очень много маленьких пакетов то очень часто приходится обращатся к сетевой карте, а это вроде не дешёвая операция.

2) есть удалённый сервер с которым болшой пинг: 150мс. с ним коннектится та же клиентская программа, но теперь всё ограничивается 64 клиентами.
Предположение: на пути до удалённого сервера есть какой то тормозной узел из за которого происходит перегрузка сети и udp пакеты удаляются.

Правильны ли мои догадки? Интересуют мнения разбирающихся людей.

Ограничения ОС на количество соединений?

нет, если слать мало пакетов то можно 512 сделать в обоих случаях

Это сообщение отредактировал(а) Аркадийй - 25.10.2010, 16:12

Ой, а я ответил в сеседней вашей ветке. Наплодили кучу тем - теперь сами мучайтесь:).

ваше приложение судя по всему критично к потере пакетов...
Насколько понимаю, ОС - windows.
Замечено, что при высокой нагрузке удп пакетами апкеты под win теряются - это раз.
Сетевые карточки бывают разные, чаще всего дешёвые аля вин-модемы в своё время. Они не могут считать crc и отсылают прерывание ЦП, что сильно грузит ЦП и сам процесс передачи. Соответствено важена не только скорость с которой идёт отправка, а так же pps.
Ещё один не маловажный момент: ваша программа закрывает соеденение при первом же потерянном пакете? если так, то такая связь работать не будет. Тут либо используйте tcp, который сам перешлёт пакет заново, либо забейте на потерянные пакеты, если это можно.

В интернете нормой является патеря пакетов в 1-5%... и с этим надо смериться.

Secandr, 
в курсе что то что пакеты теряются это нормально, но нагрузка маловата по моему для такой потери.
связь разрывается когда пинг-пакет не придёт 3 раза подряд (шлются они раз в секунду).


да


под unix разве нет?

а как pps узнаётся?

Это сообщение отредактировал(а) Аркадийй - 25.10.2010, 16:54

тесты iperf`ом показали, что windows гарантировано касячит, а линуксы и юниксы ведут себя по разному в зависимости от ядра.
попробуйте iperf`ом погонять данные между точками, проверите максимально возможную скорость в режиме tcp и в режиме udp патерю пакетов при 300 килабитной нагрузке

Аркадийй, посмотрите сначала снифером, где именно происходит потеря. 6к/сек - это не сильно много для эелеза и ОС, а вот криво напрограммировать очередь обработки этих пакетов вполне возможно. Если в таком режиме сервер влезает под 100% цпу - это косвенный сигнал о том, что что-то сделано не так.

А можно полюбопытствовать, зачем при обмене UDP 15 раз в секунду надо ещё дополнительно пинговать? по-моему, вполне достаточно считать количество непришедших подряд датаграмм - если их количество составит 45, получатся те же 3 секунды...

djamshud, у меня нет очередей обработки, но видимо действительно что то криво. надо сделать банальный пример для теста и посмотреть поменяется ли ситуация.

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

Тестовое приложение - своё? тогда лучше откажитесь от ICMP и введите UDP "пинг-датаграмму"... по крайней мере проверка связи и собственно связь будут тестироваться в сравнимых условиях.

у меня так и есть. никакого ICMP нет.

Аркадийй, тогда это всё же правильнее называть "keep alive" пакетами

Secandr, ок, учту.
потестил iperfом, потери в удп начинаются только от 4.5Mb/s, если ниже то потерь нет вообще.
пакеты по 15 байт ставил

значит касяк с обработкой вашим софтом, тут уже я не помогу
с вероятностью в 99% пакеты доходят, ОС их обрабатывает и передаёт через стек в софт, а вот что дальше происходит - вопрос.