Prima di VOS 17.1 STCP non accettava una richiesta di connessione TCP a meno che l'applicazione server non avesse chiamato la funzione di accettazione. Le richieste di connessione sono state messe in una coda di attesa, ma non è stata inviata alcuna risposta fino a quando una chiamata di accettazione non ha rimosso la richiesta dalla coda di attesa. Una volta che la coda backlog riempita, l'STCP inviava un reset in risposta a una richiesta di connessione.
A partire dalla release 17.1 la dinamica delle connessioni TCP è cambiata. Ora, quando arriva una richiesta di connessione, supponendo che la coda arretrata non sia stata riempita, lo stack STCP invierà immediatamente una risposta accettando la connessione. La connessione viene quindi inserita nella coda backlog. Una volta che la coda backlog riempie le successive richieste di connessione non viene inviata una risposta. Quando le chiamate dell'applicazione server accettano la connessione nella parte anteriore della coda backlog viene rimossa. Questo comportamento è ora simile al modo in cui si comportano gli stack TCP sulla maggior parte degli altri sistemi operativi.
In circostanze normali questo cambiamento di dinamica non porterà ad alcun cambiamento notevole nel modo in cui si comportano il server o le applicazioni client. Tuttavia, se l'applicazione server rallenta o le connessioni arrivano più velocemente del previsto, le connessioni possono rimanere nella coda del back log per un tempo prolungato. In queste circostanze si possono notare alcuni comportamenti interessanti.
La seguente tabella fornisce un riepilogo di ciò che accade quando una richiesta di connessione viene inserita nella coda di attesa in base alle azioni del cliente. Il client può non fare nulla, in attesa che l'applicazione server invii i dati, può inviare dati e/o può chiudere la connessione con un flag FIN (finale) (chiusura normale) o RST (reset) (chiusura anomala). Le prime 4 colonne si comportano come ci si aspetta. Le chiamate dell'applicazione server accettano di ricevere un socket dalla coda in arretrato e poi chiamano recv e si bloccano se non ci sono dati o ricevono dati e/o un'indicazione di fine file a seconda di cosa c'è nel socket. Sono le ultime 4 colonne che devono essere esaminate più da vicino.
| Niente nella presa | Dati nella presa | FIN nella presa | Dati nella presa/
FIN nella presa |
Dati nella presa/
FIN nella presa/ Presa cliente andata |
FIN nella presa/
Presa cliente andata |
Dati nella presa/
Reset inviato |
Reset Invio | ||
| Accetta | Presa di ritorno | Presa di ritorno | Presa di ritorno | Presa di ritorno | Presa di ritorno | Presa di ritorno | Si blocca | Si blocca | |
| Prima recv | Si blocca | Restituisce i dati | Restituisce EOF | Restituisce i dati | Restituisce l'errore di reset | Restituisce EOF | |||
| Secondo Recv | Si blocca | Restituisce EOF |
Dati nella presa / FIN nella presa / Presa cliente andata
In questo scenario il cliente ha inviato alcuni dati e ha interrotto la connessione. La 17.1 release di STCP riconoscerà tutti i dati che sono stati inviati, ma non riconoscerà il FIN fino a quando i dati nella coda di ricezione non saranno stati consegnati all'applicazione. Di conseguenza il FIN del cliente sarà ritrasmesso fino alla scadenza del timer di ritrasmissione del cliente. Un'applicazione client ben scritta aspetterà che l'applicazione server spenga il suo lato della connessione in modo che quando il FIN si interrompe, il client venga avvisato di un errore. Tuttavia, se l'applicazione client si limita a chiudere il socket senza attendere l'indicazione del server, non saprà che i dati inviati potrebbero essere andati persi.
Quando l'applicazione server chiama accetta un pacchetto di conferma duplicato, riconoscendo i dati ma non il FIN viene inviato. Dal momento che il client ha abbattuto il suo socket, risponde con un reset. Il reset cancella il socket sul lato server. L'applicazione server otterrà un errore di reset sia sulla prima che sulla seconda chiamata a recv a seconda del tempo che intercorre tra la chiamata da accettare e la chiamata alla prima recv. Se questo tempo è più veloce del tempo necessario per ottenere ed elaborare il pacchetto di reset del client, l'applicazione server vedrà i dati. In entrambi i casi l'applicazione server saprà che la connessione è stata effettuata e che è stata interrotta.
FIN nella presa / Presa cliente andata
Questo si differenzia dallo scenario precedente in quanto non ci sono dati nel socket. Quando non ci sono dati, il FIN viene riconosciuto. L'accettazione restituisce il socket e il recv restituisce un EOF che indica che ha ricevuto il FIN. Qualsiasi tentativo di scrivere al socket, compresa la sua chiusura si tradurrà in un reset che verrà restituito perché il cliente non ha più il socket corrispondente.
Dati nella presa / Reset inviato
Qui il cliente invia alcuni dati e poi invia un reset. Ci possono essere molte ragioni per il reset; una comune è l'applicazione che spegne il socket e lo stack TCP inviando un reset immediatamente o inviando un reset dopo non aver ottenuto un riconoscimento per il pacchetto FIN. Questo è simile al primo scenario, ma lo stack TCP del client invia un reset prima di abbattere il suo socket invece di abbattere solo il socket. Anche in questo caso, un'applicazione client ben scritta vedrà questo come un errore; un'applicazione non così ben scritta non vedrà un errore.
Il socket del server viene abbattuto e tutti i dati vengono scartati alla ricezione del reset, in modo che l'applicazione del server non veda nemmeno l'indicazione che è stata stabilita una connessione; si blocca in attesa di un'altra connessione.
Reset inviato
Anche in questo caso il reset rimuove efficacemente la presa dalla coda arretrata in modo che l'accettante non la veda e attenda un'altra richiesta di connessione.
Cosa significa veramente tutto questo? In primo luogo, le applicazioni client possono ora ottenere una risposta di connessione più veloce, ma potrebbero dover attendere più a lungo per qualsiasi tipo di banner o messaggio a livello di applicazione. Eventuali timeout per questo banner/messaggio potrebbero dover essere regolati verso l'alto. In secondo luogo, le applicazioni server devono essere preparate a gestire un errore della chiamata recv immediatamente dopo aver fatto un'accettazione. Questa è sempre stata una possibilità, ma ora la probabilità è maggiore. Infine, le applicazioni client che inviano dati al server e non si aspettano alcun tipo di messaggio di ritorno devono essere scritte per confermare che l'applicazione server ha chiuso correttamente la connessione o rischiano di perdere inconsapevolmente i dati. Anche in questo caso, questa possibilità è sempre esistita e non è un'esclusiva di STCP, ma la probabilità è ora leggermente maggiore.