Розетка неожиданно закрылась - PullRequest
0 голосов
/ 22 июня 2009

Я пишу тестовую программу для сервера. В тестовом приложении я пытаюсь подключить большое количество клиентов к серверу, но через некоторое время появляются различные ошибки, подобные этим:

Connection reset by peer: socket write error                   

или

java.net.SocketException: Connection reset                     

или

java.net.ConnectException: Connection refused: connect

Я использую новый сокет для каждого клиента, подключаемого к серверу.

Может ли кто-нибудь просветить меня об этом странном поведении?

Ответы [ 3 ]

0 голосов
/ 26 июня 2009

Ваш веб-сервер / сервер приложений может одновременно обслуживать только ограниченное количество клиентов.

Вы получите сообщение об отказе / сбросе соединения при достижении этого предела.

Надеюсь, что ответит на ваш вопрос.

Приветствия

0 голосов
/ 30 июня 2009

К сожалению, вы не предоставили подробную информацию о природе вашего сервера. Я полагаю, вы пишете типичный TCP-сервер. В этом ответе я не расскажу о каких-либо специфических для Java деталях.

Краткий совет: вставьте задержку между подключениями клиентов. Без этого вы активно симулируете DoS-атаку на ваш сервер.

Для более длинного, прочитайте ниже.

Обычно TCP-сервер создает только 1 прослушивания в режиме ожидания, вызывая (в прекрасном интерфейсе C) функцию int sockfd = socket(...) и передавая результат (sockfd в нашем случае) в bind() и listen() функции. После этой подготовки сервер вызовет accept(), что приведет к сну сервера (если сокет был отмечен как блокирующий), и если клиент на другой стороне Земли начнет вызывать функцию connect(), чем accept() (на стороне сервера) с поддержкой ядра ОС создаст подключенный сокет .

Фактическое количество возможных ожидающих подключений можно узнать, взглянув на функцию listen(). listen() имеет параметр backlog , который определяет максимальное количество соединений, которое ядро ​​ OS должно ставить в очередь в сокет (это в основном сумма всех соединений в SYN_RCVD и ESTABLISHED состояния). Исторически рекомендованное значение для backlog в 1980-х годах было чем-то вроде 5, что в наши дни явно жалкое. Например, во FreeBSD 7.2 жесткое ограничение для отставание можно угадать, набрав:

% sysctl kern.ipc.somaxconn
kern.ipc.somaxconn: 128

и в Fedora 10:

% cat /proc/sys/net/core/somaxconn
128

P.S.
Извините за мой ужасный английский.

0 голосов
/ 22 июня 2009

Существуют ограничения по ОС и веб-серверу, как быстро и сколько соединений вы можете начать / принять. Если вы хотите провести тестирование производительности на сервере, попробуйте Apache JMeter, поскольку он имеет решения для этих ограничений.

...