8
votes

Java Socketchaannel ne détecte pas la déconnexion?

J'ai une prise en courant à l'aide de sélecteurs. J'essaie de vérifier si mon socket est connecté au serveur ou non.

Boolean connected = _channel.isConnected();


3 commentaires

Je suis confus que quelqu'un continue à changer le titre de mes questions. Que se passe t-il ici?


Avec le code ci-dessus, vous vérifiez si le SocketCannel est toujours connecté. Alors, qu'est-ce que vous avez testé exactement, la prise, comme indiqué dans votre question ou dans la chaîne comme décrit dans le titre et indiquée dans le code? Juste demander, parce que les gens ont commencé à révéler ma réponse ... (sans expliquer pourquoi ...)


1- Vous fermez manuellement la prise, en appelant la méthode, c'est pourquoi vous obtenez FALSE après que vous avez déconnecté du serveur, dans mon cas, j'essaie de détecter s'il y avait un problème de déconnexion, par exemple "perte de connexion", donc la prise Ne détectera pas que c'est déconnecté sauf si j'essaie d'envoyer un message au serveur et d'obtenir une exception. 2- J'ai également mentionné que j'utilise un sélecteur. Donc, la méthode isconnected ne montre pas si je suis connecté au serveur ou non, mais cela indique si ma prise est toujours connectée au sélecteur ou non, ce qui retourne vrai tant que ma prise est connectée au sélecteur.


3 Réponses :


7
votes

Un canal de prise peut être connecté en invoquant sa méthode de connexion; Une fois connecté, un canal de prise reste connecté jusqu'à ce qu'il soit fermé.

Le canal n'est pas fermé lorsque le serveur n'est plus disponible, en raison d'une connexion physique cassée ou d'une défaillance du serveur. Donc, une fois qu'une connexion a été établie, isconnected () retournera true jusqu'à ce que vous fermiez la chaîne de votre côté.

Si vous voulez vérifier , Si le serveur est toujours disponible, envoyez un octet à la sortie Sockets. Si vous obtenez une exception, le serveur est indisponible (connexion perdue).


edit

pour EJP - Quelque code pour tester et reconsidérer Votre commentaire et réponse: xxx

sortie sur ma machine est xxx


2 commentaires

Chers Downvotes - S'il vous plaît laissez un commentaire, si vous pensez que la réponse n'est pas utile. Au moins le commentaire EJP est incorrect comme sa réponse ... La question portait sur Socketchaannels et je suis toujours sûre, cela explique, pourquoi éteindre l'aéroport n'entraîne pas un isconnecté () == faux .


Je suis d'accord avec Andreas: Les bowvotes inexpliqués sont inutiles ou pires. Je viens chercher des bowvotes inexpliqués comme un simple vandalisme de site.



13
votes

Généralement si vous désactivez le réseau de niveau du système d'exploitation, les écrites à la prise devraient lancer des exceptions, vous savez donc que la connexion est cassée.

Cependant, plus généralement, nous ne pouvons pas être sûrs que si un paquet est livré. En Java (probablement aussi), il n'ya aucun moyen de vérifier si un paquet est ACK'ED.

Même si nous pouvons vérifier TCP ACKS, il ne garantit pas que le serveur a reçu ou traité le paquet. Cela signifie seulement que la machine cible a reçu le paquet et la tamponnée en mémoire. Beaucoup de choses peuvent aller mal après cela.

Donc, si vous voulez vraiment sûr, vous ne pouvez pas compter sur le protocole de transport. Vous devez avoir niveau d'application ACK , c'est-à-dire que l'application Server écrit un message ACK après avoir reçu et traité un message du client.

du point de vue du client, il écrit un message au serveur, puis essaie de lire ACK du serveur. Si cela l'obtient, il peut être certain que son message est reçu et traité. S'il ne parvient pas d'obtenir ACK, Eh bien, cela n'a aucune idée de ce qui s'est passé. Empireusement, le plus probable TCP a échoué. Le prochain possiblity est ce serveur s'est écrasé. Il est également possible que tout s'est bien passé, sauf que l'ACK n'a pas pu atteindre le client.


0 commentaires

4
votes

Isconnected () vous indique si vous avez connecté l'objet canal , que vous avez, et il n'est pas spécifié de renvoyer false après la fermeture, bien que ce soit apparemment : Voir la réponse d'Andreas. Ce n'est pas là pour vous dire si la connexion sous-jacente est toujours là. Vous pouvez seulement dire que en l'utilisant: -1 à partir d'une lecture, ou une exception, vous indique que.


3 commentaires

isconnected () renvoie false sur ma machine lorsque je ferme le canal sur le serveur distant. Voir ma réponse pour un exemple de travail.


-1 de lecture ne fonctionne pas aussi. J'ai ajouté une lecture et elle bloquée (en attente d'octets). Ensuite, j'ai tiré le câble réseau et l'application a maintenu le blocage (no -1 en conséquence).


Oui, -1 de lecture détecte une fermeture ordonnée. Le seul moyen de détecter une fermeture désordonnée avec une lecture et aucun écrit est via un délai de lecture, qui offre une exception.