2010-03-29 9 views
5

J'écris un client et un serveur TCP personnalisé et en faisant une tonne de demandes (60 000 pour être exact) je commence à obtenir cette erreur de socket de 10048, dont should mean "l'adresse est déjà utilisée."Erreur de socket de 10048 sur le client? Causes possibles?

L'erreur persiste sauf si je mets le processus en pause pendant 2 ou 3 minutes, puis recommence, puis commence à afficher la même erreur peu de temps après le redémarrage. Si je mets en pause le processus client et redémarre le processus du serveur, je reçois toujours la même erreur sur le client. C'est donc un problème côté client complet.

Cela n'a pas de sens cependant, cette erreur se produit généralement lors de la liaison et cette erreur se produit sur le client et non sur le serveur. Quelles pourraient être les raisons possibles?

Un petit extrait de mon initialisation:

TcpClient client = new TcpClient(); 
client.Connect("XXXXX -- some ip", 25000); 
client.NoDelay = true; 
NetworkStream clientStream = client.GetStream(); 

De plus, tout semble fonctionner très bien (y compris la quantité de temps qu'il faut pour envoyer les deux sens) et cela fonctionne parfaitement lors de l'utilisation 127.0.0.1 mais quand le mettre sur un autre ordinateur LAN je commence à obtenir l'erreur 10048.

Y a-t-il quelque chose qui ne va pas dans la façon dont je l'initialise? Quoi d'autre pourrait causer cette erreur du côté du client?

Répondre

9

Voir http://msdn.microsoft.com/en-us/library/e160993d%28v=VS.90%29.aspx SetSocketOption. Vous avez besoin de DontLinger ou ReuseAddr, ou les deux, je ne suis pas sûr. Fondamentalement, vos sockets sont bloqués dans l'état TIME_WAIT pendant un certain temps après avoir détruit la connexion TCP, une fois que vous en aurez assez, vous ne pourrez pas créer de nouvelles connexions client. Vérifiez cela avec la sortie du programme netstat -na.

Vous pouvez également réduire le temps que la prise reste dans l'état TIME_WAIT en changeant dans le registre : http://msdn.microsoft.com/en-us/library/aa560610%28BTS.20%29.aspx Par défaut est de 4 minutes qui peut probablement être réduite à 1 ou 2 minutes en toute sécurité, en particulier pour les tests. Clause de non-responsabilité: Je ne suis pas un gourou TCP par tous les moyens.

+0

J'ai ajouté 'client.LingerState = new LingerOption (false, 0),' et en utilisant netstat, votre droit, j'ai une charge de merde de connexions dans TIME_WAIT – Earlz

+0

Je veux dire, j'ai encore beaucoup de TIME_WAIT après avoir ajouté le bit 'LingerState' – Earlz

+0

ReuseAddr n'aide pas non plus. – Earlz

0
+0

Si c'est la raison, alors comment ça marche quand j'utilise localhost? – Earlz

+1

@Earlz: Cela peut être dû au fait que les connexions sur 127.0.0.1 utilisent une durée de vie de segment maximale très faible (0?), Car nous ne pouvons vraiment pas obtenir de paquets errants. Je n'ai pas été capable de trouver quoi que ce soit à ce sujet en faisant des recherches sur Google, mais cela aurait du sens. Vous pouvez essayer d'utiliser une interface IP et voir si cela la rend reproductible sur la machine locale - bien que cela puisse également être optimisé. Jetez également un coup d'oeil à la définition de TcpTimedWaitDelay à 30 secondes (http://msdn.microsoft.com/en-us/library/ms819739.aspx) sur le serveur, si cela est possible –