Prise fermée de manière inattendue

Question

J'écris un programme de test pour un serveur. Sur l'application de test, j'essaie de connecter un grand nombre de clients au serveur, mais après un certain temps, j'ai toutes sortes d'erreurs comme celles-ci:

Connection reset by peer: socket write error                   

ou

java.net.SocketException: Connection reset                     

ou

java.net.ConnectException: Connection refused: connect

J'utilise un nouveau socket pour chaque client que je connecte au serveur.

Quelqu'un pourrait-il m'éclairer sur ce comportement étrange?

Answer 1

Malheureusement, vous n'avez pas fourni beaucoup de détails sur la nature de votre serveur. Je suppose que vous écrivez un serveur TCP typique. Dans cette réponse, je ne parlerai d'aucun détail spécifique à Java.

Le petit conseil est le suivant: insérez un délai entre les connexions des clients. Sans cela, vous simulez activement une attaque par déni de service sur votre serveur.

Pour le plus long, lisez ci-dessous.

Habituellement, un serveur TCP crée seulement 1 écoute sockée en appelant (dans une belle interface C) int sockfd = socket (...) et en transmettant le résultat ( sockfd dans notre cas) aux fonctions bind () et listen () . Une fois ces préparatifs terminés, le serveur appelle un accept () qui le rend silencieux (si le socket est marqué comme bloquant) et si un client situé de l’autre côté de la Terre commence à appeler un serveur. connect () , alors que accept () (côté serveur) avec le support du noyau du système d’exploitation créera la socket connectée .

Le nombre réel de connexions en attente possibles peut être connu en consultant la fonction listen () . listen () a un paramètre backlog qui définit le nombre maximal de connexions que le noyau OS doit mettre en file d'attente vers le socket (il s'agit en gros d'une somme de toutes les connexions dans les états SYN_RCVD et ESTABLISHED ). Historiquement, la valeur recommandée pour l'arriéré dans les années 1980 était quelque chose comme 5, ce qui est évidemment misérable à notre époque. Dans FreeBSD 7.2, par exemple, vous pouvez deviner une limite stricte pour le backlog en tapant:

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

et dans Fedora 10:

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

P.S.
Désolé pour mon anglais terrible.

Answer 2

Votre serveur Web / application ne peut gérer qu'un nombre limité de clients à la fois.

Vous recevrez une connexion refusée / réinitialisée lorsque cette limite sera atteinte.

J'espère que cela répond à votre question.

A bientôt

Answer 3

Certains systèmes d’exploitation et serveurs Web limitent la rapidité et le nombre de connexions que vous pouvez établir / accepter. Si vous souhaitez effectuer des tests de performances sur le serveur, essayez Apache JMeter car il propose des solutions à ces problèmes.