Sblocco Chiamate alla funzione recv senza utilizzare la modalità Non-blocking

Quando si scrive un'applicazione di rete è possibile utilizzare la modalità non bloccante o la modalità di blocco. La modalità non bloccante è più flessibile e necessaria quando l'applicazione deve fare più cose, come la manutenzione di più prese. Se però l'applicazione sta facendo solo 1 cosa, per esempio leggere da un socket e scrivere i dati su un file o una coda, allora l'uso della modalità di blocco può ridurre significativamente la complessità dell'applicazione. C'è un piccolo problema con la modalità di blocco, se qualcosa va storto con la connessione l'applicazione potrebbe non saperlo mai; aspetterà per sempre i dati che non arriveranno mai.

Come può succedere? Immaginate che la vostra applicazione abbia chiamato recv e sia in attesa dei dati di un cliente. La connessione di rete del cliente è inaffidabile e l'applicazione client sta subendo ritrasmissioni multiple. Ad un certo punto lo stack TCP del client decide che la connessione deve essere terminata; notifica l'applicazione client e pulisce il socket. L'applicazione viene lasciata in attesa dei dati di una connessione che, per quanto riguarda il client, è stata chiusa. L'unico modo per risolvere il problema è terminare manualmente l'applicazione e riavviarla. La terminazione dell'applicazione lascia il socket collegato in uno stato "TIME_WAIT" che, a meno che non si sia impostata l'opzione REUSEADDR socket, impedirà di riavviare immediatamente l'applicazione e di farla legare al socket in ascolto.

Si può comunque dire ad OpenVOS di impostare un limite di tempo per l'attesa dei dati durante la chiamata recv. Il risultato è che dopo la scadenza del limite di tempo la chiamata restituirà un -1 ed errno sarà impostato su e$timeout (1081). La vostra richiesta può quindi decidere come procedere. Può terminare la connessione, dare al cliente un'altra possibilità, inviare qualcosa al cliente per testare la connessione, o qualsiasi altra risposta appropriata dell'applicazione. Il punto è che la diagnosi della situazione e la risposta sono sotto il vostro controllo.

Il programma timeout_recv.c in figura 2 è un esempio di come fare questo. Sono necessari 2 argomenti, un numero di porta da ascoltare e un timeout in unità di 1/1024 di secondo. La figura 1 mostra un esempio di esecuzione, la riga di comando (in grassetto e sottolineata) viene echeggiata perché sono fermamente convinto che tutti gli argomenti debbano essere echeggiati da programmi interattivi. Nota Ho impostato un timeout di 10 secondi (10240 / 1024). Il programma segnala quando chiama accept e se accept restituisce un timeout. Anche se non l'ho menzionato nel paragrafo precedente, il timeout funzionerà anche sulla chiamata di accettazione e il programma lo dimostra. Dopo che la connessione è stata effettuata, il programma riporta quando chiama recv e il tempo che recv ha restituito con un timeout o con dei caratteri. Ho evidenziato tutti i messaggi di timeout.

Si noti che le chiamate per impostare i limiti di tempo sono specifiche di OpenVOS (e VOS); questo approccio non funzionerà con altri sistemi operativi.

Figura 1 - Esempio di esecuzione di timeout_recv

Figura 2 - timeout_recv.c