Che cosa causa l'errore ENOTCONN?

Question

Attualmente sto mantenendo alcuni software per server Web e ho bisogno di eseguire molte operazioni di I/O. Le chiamate read(), , close() e shutdown(), se utilizzate su un socket, possono talvolta generare un errore ENOTCONN. Cosa significa esattamente questo errore? Quali sono le condizioni che l'avrebbero innescata? Non riesco mai a riprodurlo localmente ma ci sono utenti che possono farlo.

In questo momento ho appena ignorato ENOTCONN quando generato da close() e shutdown() perché sembra innocuo, ma non ne sono del tutto sicuro.

EDIT:

• Sono assolutamente sicuro che la chiamata è riuscita connect(). Controllo il suo valore di ritorno.
• ENOTCONN viene generato più spesso da close() e shutdown(). Ho visto molto raramente un aumento di read() e write()ENOTCONN.

Answer 1

Se si è certi che nulla dalla propria parte della connessione TCP stia chiudendo la connessione, mi sembra che il lato remoto stia chiudendo la connessione.

ENOTCONN, come altri hanno sottolineato, significa semplicemente che la presa non è collegata. Questo non significa necessariamente che connect non sia riuscito. Il socket potrebbe essere stato collegato in precedenza, ma non era al momento della chiamata che ha provocato ENOTCONN.

Ciò differisce da:

• ECONNRESET: l'altra estremità della connessione inviato un pacchetto TCP reset. Questo può accadere se l'altra estremità rifiuta una connessione, o non riconosce che è già connessa, tra le altre cose.
• ETIMEDOUT: generalmente si applica solo a connect. Questo può accadere se il tentativo di connessione non ha esito positivo in un lasso di tempo dipendente dal sistema.

EPIPE volte può essere restituito da qualche sistema presa legati chiamate in condizioni che sono più o meno lo stesso come ENOTCONN.Ad esempio, su alcuni sistemi, EPIPE e ENOTCONN sono anche restituiti da send.

Anche se non è insolito per shutdown per tornare ENOTCONN, dal momento che questa funzione dovrebbe abbattere la connessione TCP, sarei sorpreso di vedere close ritorno ENOTCONN. Non dovrebbe mai farlo.

Infine, come accennato DWC, EBADF non dovrebbe applicarsi nello scenario a meno che non si sta tentando alcune operazioni su un descrittore di file che è già stato close d. Avere un socket disconnesso (ovvero la connessione TCP è interrotta) non equivale a chiudere il descrittore di file associato a quel socket.

Answer 2

Transport endpoint non è collegato

La presa è associata ad un protocollo orientato alla connessione e non è stato collegato. Questo è di solito un difetto di programmazione.

Da: http://www.wlug.org.nz/ENOTCONN

Answer 3

Se sei sicuro di aver collegato correttamente, in primo luogo, ENOTCONN è più probabile essere causato sia dal fd essendo chiuso da parte vostra, mentre (forse in un altro thread?) sei nel bel mezzo di una richiesta o quando la connessione si interrompe mentre sei nel mezzo della richiesta.

In ogni caso, significa che la presa non è collegata. Vai avanti e ripulisci quella presa. È morto. Nessun problema chiamando close() o shutdown() su di esso.

Answer 4

Credo che ENOTCONN venga restituito, perché shutdown() non dovrebbe restituire ECONNRESET o altri errori più precisi.

È sbagliato supporre che l'altro lato "solo" abbia chiuso la connessione. A livello TCP, l'altra parte può solo chiudere a metà una connessione (o interromperla). La connessione è ordinaria completamente chiusa se entrambe le parti eseguono uno shutdown() (o close()). Se entrambe le parti lo fanno, shutdown() riesce effettivamente per entrambi!

Il problema è che l'arresto() ha non riuscire a ordinaria (mezza) chiudere la connessione, né come il primo per chiuderla, né come il secondo. - Dagli errori elencati nei documenti POSIX per shutdown(), ENOTCONN è il meno appropriato, poiché gli altri indicano problemi con argomenti passati a shutdown() (o problemi di risorse locali per gestire la richiesta).

Quindi cosa è successo? Al giorno d'oggi, un dispositivo NAT tra le due parti coinvolte potrebbe aver abbandonato l'associazione e inviato i pacchetti RESET come reazione. Le connessioni di reset sono così comuni per IPv4, che le si ottiene ovunque nel codice, anche mascherate come ENOTCONN in shutdown().

Un bug di codifica potrebbe essere il motivo. Ad esempio, su un socket non bloccante, connect() può restituire 0 senza indicare ancora una connessione riuscita.

Answer 5

E 'perché, al momento dello shut() del socket, si hanno dati nel buffer del socket in attesa di essere consegnati alla parte remota che ha chiuso() o spento() il suo socket di ricezione. Non ho finito di capire come funzionano i socket, sono piuttosto un noob, e non ho nemmeno trovato i file dove è implementata questa funzione di "shutdown", ma visto che praticamente non c'è un manuale utente per l'intera cosa ho iniziato a provare tutte le possibilità fino a quando ho ottenuto l'errore in un ambiente "controllato". Potrebbe essere qualcosa di diverso, ma dopo molto cercare queste sono le spiegazioni ho optato per:

• Se hai inviato i dati dopo il lato remoto ha chiuso la connessione, quando si shutdown(), si ottiene l'errore.
• Se hai inviato dati prima che il lato remoto abbia chiuso la connessione ma non sia stato ricevuto() dall'altra parte, puoi spegnere() una volta, la volta successiva che provi a shutdown(), ottieni l'errore.
• Se non si sono inviati dati, è possibile arrestare tutte le volte che si desidera, a condizione che il lato remoto non si spenga(); una volta che il lato remoto ha shutdown(), se si tenta di shutdown() e il socket era già shutdown(), si ottiene l'errore.