2009-06-25 14 views
8

Lorsque vous créez un socket Java:Comment afficher/modifier le délai de connexion socket sur Linux?

new Socket(host, port); 

Le constructeur Socket essaiera de se connecter à hôte: port avant de retourner. Sous Windows, cela échoue presque immédiatement pour les hôtes inaccessibles, mais pour Linux, cela peut prendre jusqu'à 5 minutes pour que Socket expire.

Je suis conscient que si j'ai le contrôle sur la création des sockets, je peux faire:

Socket s = new Socket(); 
s.bind(..); 
s.connect(.., timeout); 

mais je préfère avoir le système d'exploitation utilise une valeur par défaut raisonnable. Y a-t-il un moyen de changer ce paramètre sur Linux?

Merci

+0

Je pense qu'il est préférable de configurer ce délai d'attente dans chaque application. Sinon, toutes les autres applications exécutées sur cette machine seront affectées par ce paramètre. – Reginaldo

+1

D'accord, j'aimerais toujours savoir quel est le réglage si je souhaite le changer. – Kevin

+1

Si vous insistez pour changer les paramètres du système d'exploitation alors je pense que ce n'est plus une question liée à la programmation et appartient à Server Fault. – akarnokd

Répondre

7

Je pense que vous voulez /proc/sys/net/ipv4/tcp_syn_retries. La valeur par défaut est généralement 5 ou 6, ce qui revient à environ 3 minutes.

Notez qu'il s'agit de l'ensemble du système.

+0

Quelle est la durée entre chaque nouvel essai? Il semble augmenter de façon exponentielle à chaque nouvelle tentative. Où est cet ensemble? – Kevin

+0

Les intervalles augmentent, au moins jusqu'à un certain point. Ma mémoire me manque ici. Je ne me souviens pas si c'est BSD ou TCP et je ne sais pas si Linux vous donne un moyen de le contrôler. – Duck

+4

Les intervalles sont contrôlés par des valeurs appelées rtoMin, rtoMax et rtoInitial où rto signifie Round Trip Timeout. Fondamentalement, il indique le temps qu'il faudrait pour qu'un paquet fasse un aller-retour. Donc, si TCP envoie le premier msg, il attendra l'heure rtoInitial. S'il ne parvient pas à obtenir une réponse, il doublera le rto (et ajoutera de la valeur de gigue), puis réessayera. Cela continuera jusqu'à maxRetries. La valeur actuelle de rto ne dépassera jamais rtoMax. –

0

Je crois comprendre que cela dépend du délai d'attente par défaut TCP/IP du système (240 secondes par défaut?) ... une option est d'essayer de peaufiner ceux-ci, mais cela pourrait affecter d'autres programmes sur le même machine qui s'appuient sur la valeur du délai d'expiration. Dans ce cas, il peut être plus sûr de simplement réduire la valeur "timeout" de votre appel Java connect().

4

Je vous déconseille de modifier les paramètres du système d'exploitation car cela pourrait affecter d'autres applications de façon inattendue. La méthode Socket.setSoTimeout() pourrait vous aider aussi.

+2

Puis-je demander la raison pour la downvote afin que je puisse en tirer des leçons? – akarnokd

+2

Je pense que SO_TIMEOUT s'applique à lire mais pas à se connecter, donc c'est peut-être pourquoi. Cependant, je ne peux pas trouver de vérification pour le moment. –

2

Il est BTW pas tout à fait correct, que Linux et Windows se comportent différemment ici. Outre les tentatives SYN initial (qui peuvent être configurées sous Linux et Windows), l'état voisin ainsi que d'autres routeurs envoyant des paquets RST jouent également un rôle.

Si une tentative de connexion sur Windows échoue immédiatement, il est probable qu'elle ait été augmentée RST par un routeur ou que le voisin ait été reconnu comme inaccessible au niveau ARP. Essayez la commande arp -a -v sur Windows pour voir les hôtes inaccessibles - qui sont rejetés rapidement.

Pour Linux, utilisez ip neigh pour afficher l'état d'accessibilité des stations de votre réseau local.