Vérifier si une ClientSocket a déconnecté dans java se bloque

C'est un suivi à:

cette question

En gros, j'ai un serveur boucle qui gère une connexion à un solitaire client. À un moment donné dans la boucle, si un ClientSocket existe, il tente une lecture pour vérifier si le client est toujours connecté:

if (bufferedReader.read()==-1 ) {
       logger.info("CONNECTION TERMINATED!");
       clientSocket.close(); 
       setUpSocket(); //sets up the server to reconnect to the client
}else{
        sendHeartBeat(); //Send a heartbeat to the client
}

Le problème est, qu'une fois qu'un socket a été créé l'application se bloque sur la lecture, je suppose attente pour les données qui ne viendra jamais, depuis que le client n'envoie jamais sur le serveur. Avant c'était OK, parce que cela correctement traitées se déconnecte (la lecture serait finalement échouer lorsque le client s'est déconnecté), et la boucle serait tenter de rétablir la connexion. Cependant, j'ai maintenant ajouté ci-dessus sendHeartBeat() la méthode, qui, périodiquement, permet au client de savoir que le serveur est encore en place. Si la lecture est tenue le fil puis les battements de cœur de ne jamais arriver!

Donc, je suppose que je suis en train de tester si la connexion est toujours pas correctement. Je pourrais, comme un rapide hack, exécutez la bufferedReader.read() dans un autre thread, mais je vais avoir toutes sortes de problèmes de concurrence que je n'ai vraiment pas envie de traiter avec.

Donc la question est quelques fois:
1) Suis-je vérifier pour un client déconnecter correctement?
2) Si non, comment dois-je faire?
3) Si je le fais correctement comment je puis-je obtenir le lire pour ne pas tenir les processus en otage? Ou est-threading le seul moyen?

OriginalL'auteur Alex | 2009-03-30

  1. 9

    Lorsque vous créez votre douille, d'abord définir un délai d'attente:

    private int timeout    = 10000;
private int maxTimeout = 25000;

clientSocket.setSoTimeout(timeout);

    Avec cela, si un temps de lecture, vous obtiendrez java.net.SocketTimeoutException (ce que vous avez à les attraper). Ainsi, vous pourriez faire quelque chose comme cela, en supposant que vous avez déjà réglé l'SO_TIMEOUT comme indiqué ci-dessus, et en supposant que le rythme cardiaque obtiendrez toujours une réponse du système à distance:

    volatile long lastReadTime;

try {
    bufferedReader.read();
    lastReadTime = System.currentTimeMillis();
} catch (SocketTimeoutException e) {
    if (!isConnectionAlive()) {
        logger.info("CONNECTION TERMINATED!");
        clientSocket.close(); 
        setUpSocket(); //sets up the server to reconnect to the client
    } else {
        sendHeartBeat(); //Send a heartbeat to the client
    }
}

public boolean isConnectionAlive() {
    return System.currentTimeMillis() - lastReadTime < maxTimeout;
}

    Une façon courante de ce traitement est de définir le délai d'expiration pour un certain nombre (disons 10 secondes), puis en gardant la trace de la dernière fois que vous avez réussi à lire à partir de la prise. Si 2,5 fois votre délai d'attente écoulé, puis abandonné sur le client et fermer le socket (donc l'envoi d'un paquet FIN de l'autre côté, juste au cas où).

    Si le rythme cardiaque va pas obtenir aucune réponse du système à distance, mais est simplement un moyen de l'en fin de compte générer une IOException plus tôt lors de la connexion a chuté vers le bas, alors vous pourriez le faire (en supposant que le sendHeartBeat lui-même ne sera pas jeter un IOException):

    try {
    if (bufferedReader.read() == -1) {
        logger.info("CONNECTION TERMINATED with EOF!");
        resetConnection();
    }
} catch (SocketTimeoutException e) {
    //This just means our read timed out ... the socket is still good
    sendHeartBeat(); //Send a heartbeat to the client
} catch (IOException e) {
    logger.info("CONNECTION TERMINATED with Exception " + e.getMessage());
    resetConnection();
}

....

private void resetConnection() {
    clientSocket.close(); 
    setUpSocket(); //sets up the server to reconnect to the client
}
    Mais la lecture ne va pas renvoyer la valeur -1 si le client est là, c'est exact?
    J'ai ajouté un exemple de code pour montrer
    J'ai amélioré le code exemple pour utiliser plus de votre code.
    En fait, la connexion pourrait encore exister dans votre code si rien n'a été envoyée pour le temps > maxTimeout, mais le client est toujours connecté.
    Mais dans ce cas, vous aurait envoyé deux battements de coeur avec aucune réponse, alors cela implique que la distance n'est plus en train de parler.

    OriginalL'auteur Eddie

  2. 1

    Vous de vérifier correctement, vous pouvez ajouter un try catch avec IOException dans le cas où il se produit.

    Il y a un moyen pour éviter les threads, vous pouvez utiliser un Sélecteur avec un non-bloking socket.

    public void initialize(){
  //create selector
  Selector selector = Selector.open();
  ServerSocketChannel acceptSocket = ServerSocketChannel.open();
  acceptSocket.configureBlocking(false);
  String bindIp = "127.0.0.1";
  int bindPort = 80;
  acceptSocket.socket().bind(new InetSocketAddress(bindIp, bindPort));
  //register socket in selector for ACCEPT operation
  acceptSocket.register(selector, SelectionKey.OP_ACCEPT);
  this.selector = selector;
  this.serverSocketChannel = serverSocketChannel;
}

public void serverStuff() {
   selector.select(maxMillisecondsToWait);
   Set<SelectionKey> selectedKeys = selector.selectedKeys();
   if( selectedKeys.size() > 0 )
   {
      if( key.isAcceptable() ){
        //you can accept a new connection
        SocketChannel clientSk = serverSocketChannel.accept();
        clientSk.configureBlocking(false);
        //register your SocketChannel in the selector for READ operations
    clientSk.register(selector, SelectionKey.OP_READ);
      } else if( key.isReadable() ){
        //you can read from your socket.
        //it will return you -1 if the connection has been closed
      }
   }

   if( shouldSendHeartBeat() ){
     SendHeartBeat
   }
}

    OriginalL'auteur no_ripcord

  3. 0

    Vous devez ajouter la vérification des erreurs dans votre déconnexion de détection. Parfois, une IOException peut être levée lorsque la connexion à l'autre extrémité est perdu.

    J'ai peur que le filetage est inévitable ici. Si vous ne voulez pas bloquer l'exécution de votre code, vous devez créer un thread séparé.

    Vous dites que j'ai pour exécuter le bufferedReader.run() dans un autre thread, c'est exact?
    Tôt ou tard, vous aurez besoin de thread. Il serait préférable de sortir bufferedReader.lire dans un thread séparé. En fait, tous les socket communications doivent être dans un fil de leur propre.

    OriginalL'auteur kgiannakakis