Perché è impossibile, senza tentare di I / O, rilevare che il socket TCP è stato chiuso con grazia dal peer?

A seguito di una recente domanda , mi chiedo perché sia ​​impossibile in Java, senza tentare di leggere / scrivere su un socket TCP, rilevare che il socket è stato chiuso con grazia dal peer? Questo sembra essere il caso indipendentemente dal fatto che si utilizzi il pre-NIO Socketo il NIO SocketChannel.

Quando un peer chiude con grazia una connessione TCP, gli stack TCP su entrambi i lati della connessione ne sono a conoscenza. Il lato server (quello che avvia l'arresto) finisce nello stato FIN_WAIT2, mentre il lato client (quello che non risponde esplicitamente allo spegnimento) finisce nello stato CLOSE_WAIT. Perché non c'è un metodo Socketo SocketChannelche può interrogare lo stack TCP per vedere se la connessione TCP sottostante è stata terminata? È che lo stack TCP non fornisce tali informazioni sullo stato? O è una decisione progettuale per evitare una chiamata costosa nel kernel?

Con l'aiuto degli utenti che hanno già pubblicato alcune risposte a questa domanda, penso di vedere da dove potrebbe provenire il problema. Il lato che non chiude esplicitamente la connessione finisce nello stato TCP, CLOSE_WAITil che significa che la connessione è in fase di chiusura e attende che il lato esegua la propria CLOSEoperazione. Suppongo sia abbastanza giusto che isConnectedritorni truee isClosedritorni false, ma perché non c'è qualcosa di simile isClosing?

Di seguito sono riportate le classi di test che utilizzano socket pre-NIO. Ma risultati identici si ottengono usando NIO.

import java.net.ServerSocket;
import java.net.Socket;

public class MyServer {
  public static void main(String[] args) throws Exception {
    final ServerSocket ss = new ServerSocket(12345);
    final Socket cs = ss.accept();
    System.out.println("Accepted connection");
    Thread.sleep(5000);
    cs.close();
    System.out.println("Closed connection");
    ss.close();
    Thread.sleep(100000);
  }
}


import java.net.Socket;

public class MyClient {
  public static void main(String[] args) throws Exception {
    final Socket s = new Socket("localhost", 12345);
    for (int i = 0; i < 10; i++) {
      System.out.println("connected: " + s.isConnected() + 
        ", closed: " + s.isClosed());
      Thread.sleep(1000);
    }
    Thread.sleep(100000);
  }
}

Quando il client di prova si connette al server di prova, l'output rimane invariato anche dopo che il server ha avviato l'arresto della connessione:

connected: true, closed: false
connected: true, closed: false
...

Ho usato spesso i socket, principalmente con i selettori, e sebbene non sia un esperto di OSI di rete, dalla mia comprensione, chiamare shutdownOutput()un socket invia effettivamente qualcosa sulla rete (FIN) che sveglia il mio selettore dall'altra parte (stesso comportamento in C linguaggio). Qui hai il rilevamento : rilevare effettivamente un'operazione di lettura che non andrà a buon fine quando la proverai.

Nel codice che fornisci, la chiusura del socket interromperà sia i flussi di input che quelli di output, senza possibilità di leggere i dati che potrebbero essere disponibili, perdendoli quindi. Il Socket.close()metodo Java esegue una disconnessione "aggraziata" (opposta a quanto pensavo inizialmente) in quanto i dati rimasti nel flusso di output verranno inviati seguiti da un FIN per segnalare la sua chiusura. La FIN verrà RICONOSCIUTA dall'altra parte, come farebbe un normale pacchetto ¹ .

Se devi aspettare che l'altro lato chiuda il suo socket, devi aspettare il suo FIN. E per raggiungere questo, si deve rilevare Socket.getInputStream().read() < 0, il che significa che dovrebbe non vicino la vostra presa di corrente, in quanto sarebbe chiudere il suoInputStream .

Da quello che ho fatto in C, e ora in Java, ottenere una chiusura così sincronizzata dovrebbe essere fatto in questo modo:

1. Uscita del socket di spegnimento (invia FIN dall'altra parte, questa è l'ultima cosa che verrà mai inviata da questo socket). L'input è ancora aperto in modo da poter read()rilevare il telecomandoclose()
2. Leggi il socket InputStreamfino a quando non riceviamo la risposta-FIN dall'altra estremità (poiché rileverà la FIN, passerà attraverso lo stesso grazioso processo di disconnessione). Questo è importante su alcuni sistemi operativi poiché in realtà non chiudono il socket fintanto che uno dei suoi buffer contiene ancora dati. Sono chiamati socket "fantasma" e utilizzano i numeri dei descrittori nel sistema operativo (questo potrebbe non essere più un problema con il sistema operativo moderno)
3. Chiudere il socket (chiamando Socket.close()o chiudendo il suo InputStreamor OutputStream)

Come mostrato nel seguente frammento di Java:

public void synchronizedClose(Socket sok) {
    InputStream is = sok.getInputStream();
    sok.shutdownOutput(); // Sends the 'FIN' on the network
    while (is.read() > 0) ; // "read()" returns '-1' when the 'FIN' is reached
    sok.close(); // or is.close(); Now we can close the Socket
}

Ovviamente entrambe le parti devono usare lo stesso modo di chiusura, o la parte mittente potrebbe sempre inviare dati sufficienti per mantenere il whileciclo occupato (ad esempio se la parte mittente sta solo inviando dati e non sta mai leggendo per rilevare la terminazione della connessione. Il che è goffo, ma potresti non avere il controllo su questo).

Come ha sottolineato @WarrenDew nel suo commento, scartare i dati nel programma (livello applicazione) induce una disconnessione non gradevole a livello applicazione: sebbene tutti i dati siano stati ricevuti a livello TCP (il whileciclo), vengono scartati.

¹ : Da " Networking fondamentale in Java ": vedi fig. 3.3 p.45, e l'intero §3.7, pp 43-48

Penso che questa sia più una questione di programmazione socket. Java sta solo seguendo la tradizione della programmazione socket.

Da Wikipedia :

TCP fornisce una consegna ordinata e affidabile di un flusso di byte da un programma su un computer a un altro programma su un altro computer.

Una volta terminato l'handshake, TCP non fa alcuna distinzione tra due endpoint (client e server). Il termine "client" e "server" è principalmente per comodità. Quindi, il "server" potrebbe inviare dati e il "client" potrebbe inviare altri dati contemporaneamente tra loro.

Anche il termine "Chiudi" è fuorviante. C'è solo la dichiarazione FIN, che significa "Non ti invierò altre cose". Ma questo non significa che non ci siano pacchetti in volo, o che l'altro non abbia altro da dire. Se si implementa la posta ordinaria come livello di collegamento dati o se il pacchetto ha percorso percorsi diversi, è possibile che il destinatario riceva i pacchetti nell'ordine sbagliato. TCP sa come risolvere questo problema per te.

Inoltre, come programma, potresti non avere il tempo di continuare a controllare cosa c'è nel buffer. Quindi, a tuo piacimento puoi controllare cosa c'è nel buffer. Tutto sommato, l'attuale implementazione del socket non è così male. Se effettivamente ci fosse isPeerClosed (), questa è una chiamata extra che devi fare ogni volta che vuoi chiamare read.

L'API dei socket sottostante non dispone di tale notifica.

Lo stack TCP mittente non invierà comunque il bit FIN fino all'ultimo pacchetto, quindi potrebbero esserci molti dati memorizzati nel buffer da quando l'applicazione mittente ha chiuso logicamente il suo socket prima ancora che i dati vengano inviati. Allo stesso modo, i dati memorizzati nel buffer perché la rete è più veloce dell'applicazione ricevente (non lo so, forse lo stai trasmettendo su una connessione più lenta) potrebbero essere significativi per il ricevitore e non vorresti che l'applicazione ricevente lo scarti solo perché il bit FIN è stato ricevuto dallo stack.

Dal momento che nessuna delle risposte finora risponde completamente alla domanda, riassumo la mia attuale comprensione del problema.

Quando viene stabilita una connessione TCP e un peer chiama close()o shutdownOutput()sul proprio socket, il socket sull'altro lato della connessione passa allo CLOSE_WAITstato. In linea di principio, è possibile scoprire dallo stack TCP se un socket è in CLOSE_WAITstato senza chiamare read/recv(ad esempio, getsockopt()su Linux: http://www.developerweb.net/forum/showthread.php?t=4395 ), ma non è così portatile.

La Socketclasse di Java sembra essere progettata per fornire un'astrazione paragonabile a un socket TCP BSD, probabilmente perché questo è il livello di astrazione a cui le persone sono abituate quando programmano applicazioni TCP / IP. I socket BSD sono una generalizzazione che supporta socket diversi da quelli INET (ad esempio, TCP), quindi non forniscono un modo portabile per scoprire lo stato TCP di un socket.

Non esiste un metodo simile isCloseWait() perché le persone abituate a programmare applicazioni TCP al livello di astrazione offerto dai socket BSD non si aspettano che Java fornisca metodi aggiuntivi.

È possibile rilevare se il lato remoto di una connessione socket (TCP) è stato chiuso con il metodo java.net.Socket.sendUrgentData (int) e rilevare l'IOException che genera se il lato remoto è inattivo. Questo è stato testato tra Java-Java e Java-C.

Ciò evita il problema di progettare il protocollo di comunicazione per utilizzare una sorta di meccanismo di ping. Disabilitando OOBInline su un socket (setOOBInline (false), tutti i dati OOB ricevuti vengono eliminati silenziosamente, ma i dati OOB possono comunque essere inviati. Se il lato remoto viene chiuso, viene tentato un ripristino della connessione, non riesce e causa la generazione di alcune IOException .

Se utilizzi effettivamente i dati OOB nel tuo protocollo, il tuo chilometraggio potrebbe variare.

lo stack Java IO invia definitivamente FIN quando viene distrutto in seguito a un improvviso smontaggio. Non ha senso che tu non possa rilevarlo, b / c la maggior parte dei client invia il FIN solo se stanno interrompendo la connessione.

... un altro motivo per cui sto davvero iniziando a odiare le classi Java di NIO. Sembra che sia tutto un po 'per metà.

È un argomento interessante. Ho scavato nel codice Java solo ora per verificare. Dalla mia scoperta, ci sono due problemi distinti: il primo è lo stesso TCP RFC, che consente al socket chiuso da remoto di trasmettere dati in half-duplex, quindi un socket chiuso da remoto è ancora mezzo aperto. Come per l'RFC, RST non chiude la connessione, è necessario inviare un comando ABORT esplicito; quindi Java consente l'invio di dati tramite socket semichiusi

(Esistono due metodi per leggere lo stato di chiusura su entrambi gli endpoint.)

L'altro problema è che l'implementazione dice che questo comportamento è opzionale. Poiché Java si sforza di essere portabile, ha implementato la migliore funzionalità comune. Il mantenimento di una mappa di (OS, implementazione di half duplex) sarebbe stato un problema, immagino.

Questo è un difetto delle classi socket OO di Java (e di tutte le altre che ho esaminato): nessun accesso alla chiamata di sistema select.

Risposta corretta in C:

struct timeval tp;  
fd_set in;  
fd_set out;  
fd_set err;  

FD_ZERO (in);  
FD_ZERO (out);  
FD_ZERO (err);  

FD_SET(socket_handle, err);  

tp.tv_sec = 0; /* or however long you want to wait */  
tp.tv_usec = 0;  
select(socket_handle + 1, in, out, err, &tp);  

if (FD_ISSET(socket_handle, err) {  
   /* handle closed socket */  
}  

Ecco una soluzione alternativa scadente. Usa SSL;) e SSL esegue una stretta stretta di mano durante lo smontaggio in modo da essere avvisato della chiusura del socket (la maggior parte delle implementazioni sembra eseguire un corretto smontaggio della stretta di mano).

La ragione di questo comportamento (che non è specifico di Java) è il fatto che non si ottengono informazioni sullo stato dallo stack TCP. Dopotutto, un socket è solo un altro handle di file e non puoi scoprire se ci sono dati effettivi da leggere da esso senza effettivamente provare a ( select(2)non aiuta lì, segnala solo che puoi provare senza bloccare).

Per ulteriori informazioni, vedere le domande frequenti sul socket Unix .

Solo le scritture richiedono lo scambio di pacchetti, il che consente di determinare la perdita di connessione. Una soluzione comune consiste nell'usare l'opzione KEEP ALIVE.

Quando si tratta di gestire socket Java semiaperti, si potrebbe voler dare un'occhiata a isInputShutdown () e isOutputShutdown () .