RFC: 793 PROTOCOLLO DI CONTROLLO DELLA TRASMISSIONE DARPA INTERNET PROGRAM SPECIFICHE DEL PROTOCOLLO September 1981 preparato per Defense Advanced Research Projects Agency Information Processing Techniques Office 1400 Wilson Boulevard Arlington, Virginia 22209 by Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 September 1981 Protocollo di Controllo della Trasmissione (TCP) Distribuita da .::http://www.rfc.altervista.org::. INDICE DEI CONTENUTI PREFAZIONE ..................................................... iii 1. INTRODUZIONE ..................................................... 1 1.1 Motivazione ................................................... 1 1.2 Scopo ......................................................... 2 1.3 Riguardo Questo Documento ..................................... 2 1.4 Interfacce .................................................... 3 1.5 Funzionamento ................................................. 3 2. FILOSOFIA ........................................................ 7 2.1 Elementi del Sistema Interconnesso ............................ 7 2.2 Modello di Funzionamento ...................................... 7 2.3 L'Ambiente Host ............................................... 8 2.4 Interfacce .................................................... 9 2.5 Rapporto ad Altri Protocolli .................................. 9 2.6 Comunicazione Affidabile ...................................... 9 2.7 Stabilimento e Cancellazione del Collegamento ................ 10 2.8 Trasmissione dei Dati ....................................... 12 2.9 Precedenza e Sicurezza ....................................... 13 3. SPECIFICHE DEL FUNZIONAMENTO .................................... 15 3.1 Formato dell'Intestazione .................................... 15 3.2 Terminologia ................................................. 19 3.3 Sequence Number .............................................. 24 3.4 Stabilire una connessione .................................... 30 3.5 Chiudere una Connessione ..................................... 37 3.6 Precedenza e Sicurezza ....................................... 40 3.7 Trasmissione dei Dati ........................................ 40 3.8 Interfacce ................................................... 44 3.9 Esaminazione di Eventi ....................................... 52 GLOSSARIO ........................................................... 79 RIFERIMENTI ......................................................... 85 [Page i] September 1981 Protocollo di Controllo della Trasmissione [Page ii] September 1981 Protocollo di Controllo della Trasmissione PREFAZIONE Questo documento descrive il Protocollo di Controllo della Tramissione (TCP) della DoD. Ci sono state nove precedenti edizioni delle specifiche del TCP di ARPA sulle quali questo standard e' basato, e il presente testo li segue pesantemente. Ci sono stati parecchi contributi a questo lavoro, sia in termini di concetti sia in termini di testo. Questa edizione chiarisce parecchi dettagli e rimuove gli adattamenti end-of-letter, buffer-size, e ridescrive il meccanismo delle lettere come una funzione push. Jon Postel Editor RFC: 793 Replaces: RFC 761 IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5 PROTOCOLLO DI CONTROLLO DELLA TRASMISSIONE DARPA INTERNET PROGRAM SPECIFICHE DEL PROTOCOLLO 1. INTRODUZIONE Il Protocollo di Controllo della Trasmissione (TCP) e' fatto per essere usato come protocollo host-a-host altamente affidabile tra host nelle reti di comunicazione con commutazione a pacchetti, in sistemi interconnessi di tali reti. Questo documento descrive le funzioni effettuate dal Protocollo di Controllo della Trasmissione, il programma che lo implementa, la sua interfaccia ai programmi oppure utenti che richiedono suoi servizi. 1.1. Motivazione I sistemi di comunicazione con calcolatori stanno giocando un ruolo sempre piu' importante nel campo militare, governativo, e nell'ambiente civile. Questo documento concentra principalmente la sua attenzione ai requisiti delle comunicazioni tra computer militari, particolarmente alla robustezza in presenza di inattendibilitą di comunicazione e di disponibilitą in presenza di congestione, ma molti di questi problemi sono presenti anche nel campo governativo e sociale. Poiche' le reti di comunicazione strategiche e tattiche del calcolatore sono sviluppate e schierate, e' essenziale fornirgli mezzi di comunicazione e fornire protocolli di comunicazione standard tra processi che possano supportare una vasta gamma di applicazioni. In previsione delle necessita' di questi standard, la Deputy Undersecretary of Defense for Research and Engineering ha dichiarato il Transmission Control Protocol (TCP) qui descritto una base degli standard di protocolli di comunicazione per la DoD-wide. Il TCP e' un protocollo connesso-orientato, punto-a-punto affidabile progettato per entrare in una gerarchia di protocolli costituita da strati che supporti le applicazioni in piu' reti. Il TCP provvede alla comunicazione affidabile tra processi in computer host attaccati a distinte ma interconnesse reti di computer. Pochi presupposti sono stati fatti circa l'affidabilita' dei protocolli di comunicazione al di sotto del layer TCP. Il TCP presuppone che posso ottenere un servizio di datagramma semplice e potenzialmente non affidabile dai livelli sottostanti. In linea di principio, dovrebbe poter funzionare sopra un'ampia gamma di sistemi di comunicazione che variano dai collegamenti hard-wired alle reti a commutazione di paccheto o commutazione di circuito. [Page 1] September 1981 Protocollo di Controllo della Trasmissione Introduzione Il TCP e' basato sui concetti descritti da Cerf e Kahn su [1]. Il TCP rientra in una architettura a strati appena sopra il Protocollo Internet (IP) [2] che fornisce un modo al TCP di spedire e ricevere segmenti di lunghezza variabile di informazioni racchiuse nel datagramma internet "pacchetti". Il datagramma internet fornisce un mezzo per l'indirizzamento della sorgente e destinazione TCP in reti differenti. Il protocollo internet si occupa inoltre, di ogni frammentazione e riassemblamento dei segmenti TCP richiesti per realizzare il trasporto e la consegna attraverso reti multiple e gateway interconnessi. Il protocollo internet trasporta inoltre informazioni sulla precedenza, classificazione di sicurezza e comparartimenti dei segmenti TCP, cosi' queste informazioni possono essere cominicate punto-a-punto attraverso reti multiple. Strati dei Protocolli +---------------------+ | livelli-superiori | +---------------------+ | TCP | +---------------------+ | protocollo internet | +---------------------+ |comunicazione di rete| +---------------------+ Figura 1 Gran parte di questo documento e' scritto nel contesto delle implementazioni del TCP che sono co-residenti con i protocolli di livelli superiori nei computer host. Alcuni sistemi di computer saranno connessi alla rete attraverso front-end computer che allogiano gli strati di TCP e protocollo internet, cosi' come la rete specifica il sofware. Le caratteristiche del TCP descrivono un interfaccia ai protocolli di strato superiore che sembra essere attuabile anche per il caso front-end, finche' un protocollo adatto host-to-front end e' implementato. 1.2. Scopo Il TCP serve a fornire un servizio di comunicazione processo-a-processo affidabile in un contesto di reti multiple. Il TCP e' progettato per essere un protocollo host-a-host d'uso comune nelle reti multiple. 1.3 Riguardo questo Documento Questo documento rappresenta una speficazione del comportamento richiesto da ogni implementazione del TCP, entrambi nelle sue interazioni con il livello di protocollo superiore e le sue interazioni con gli altri TCP. Il resto di questa sezione offre una panoramica [Page 2] September 1981 Protocollo di Controllo della Trasmissione Introduzione veramente sommaria delle interfacce del protocollo e il funzionamento. La sezione 2 ricapitola la filosofia alla base del progetto TCP. La sezione 3 offre sia una dettagliata descrizione delle azioni richieste dal TCP quando vari eventi si verificano (arrivo di nuovi segmenti, chiamate utenti, errori, ecc.) sia i dettagli del formato dei segmenti del TCP. 1.4. Interfacce Il TCP connette da un lato all'utente oppure ai processi di applicazione e dall'altro lato a un livello di protocollo inferiore come il Protocollo Internet. L'interfaccia tra il processo di applicazione e il TCP e' illustrato in modo ragionevolmente dettagliato. Questa connessione consiste in un insieme di chiamate simili alle chiamate che un sistema operativo fornisce a un processo di applicazione per manipolare file. Per esempio, ci sono chiamate per aprire e chiudere una connessione e per spedire e ricevere dati in una connessione stabilita. E' previsto inoltre che il TCP possa comunicare in modo ansincrono con i programmi applicativi. Anche se una considerevole liberta' e' permessa agli implementatori del TCP per progettare connessione chei sono adattate a particolari ambienti di sistemi operativi, una funzionalitą minima č richiesta all'interfaccia di TCP/user per qualsiasi implementazione valida. L'interfaccia tra il TCP e il livello di protocollo sottostante e' essenzialmente non specificata eccetto che e' presupposto che ci sia un meccanismo attraverso il quale due livelli possano passare in modo ansincrono le infromazioni l'uno all'altro. Tipicamente, e' il livello piu' basso a specificare questa interfaccia. Il TCP e' progettato per lavorare in un ambiente veramente generale di reti interconnesse. Il livello piu' basso che e' presupposto durante questo documento e' il Protocollo Internet [2]. 1.5. Funzionamento Come notato prima, il principale scopo del TCP e' di fornire affidabilita' circuiti virtuali o servizi di connessione sicuri tra coppie di processi. Per fornire questo servizio oltre a un minimo di sistemi di comunicazione internet richiede i mezzi nelle seguenti aree: Trasferimento dei Dati di Base Affidabilita' Controllo del Flusso Multiplexing Connessioni Precendenza e Sicurezza Il funzionamento base del TCP in ognuna di queste aree e' descritta nei paragrafi seguenti. [Page 3] September 1981 Protocollo di Controllo di Trasmissione Introduzione Trasferimento Base dei Dati: Il TCP e' capace di trasferire un flusso continuo di otteti in ogni direzione tra i suoi utenti impacchettando alcuni otteti in segmenti per la trasmissione attraverso il sistema internet. In generale, i TCP decidono quando bloccare e 'forwardare' i dati a loro convenienza. Qualche volta gli utenti hanno bisogno di essere sicuri che tutti i dati che hanno consegnato al TCP siano stati trasmessi. Per questo scopo e' definita una funzione push. Per assicurare che i dati presentati al TCP siano attualmente trasmessi l'utente mittente indica che dovrebbe essere 'pushato' attraverso l'user ricevente. Una push induce i TCP a spedire e a trasportare subito i dati fino al punto del ricevente. Il punto esatto di push puo' non essere visibile al ricevente e la funzione push non fornisce un indicatore di contorno record. Affidabilita': Il TCP deve recuperare i dati che sono stati danneggiati, perduti, duplicati, o consegnati al di fuori del sistema di comunicazione internet. Questo e' realizzato assegnando un sequence number ad ogni otteto trasmesso, e richiedendo un riconoscimento positivo (ACK) dal TCP ricevente. Se l'ACK non e' ricevuto entro un periodo di timeout, i dati vengono ritrasmessi. Dal ricevente, i sequence number sono usati per il riordinamento esatto dei segmenti i quali possono essere ricevuti in ordine sparso e per eliminare i segmenti doppi. Il danneggiamento e' gestito aggiungendo un checksum a ogni segmento trasmesso, controllandolo alla ricezione, e scartando i segmenti danneggiati. Finche' i TCP continuano a funzionare propriamente e il sistema internet non viene completamente diviso, nessun errore di trasmissione interessera' la corretta consegna dei dati. Il TCP recupera dagli errori del sistema di comunicazione internet Controllo del Flusso: Il TCP fornisce un mezzo al ricevente al fine di governare l'ammontare dei dati spediti dal mittente. Cio' e' realizzato restituendo una window con ogni ACK indicando una gamma di sequence number accettabili oltre all'ultimo segmento ricevuto con successo. La window indica un numero di otteti accettati che il mittente puo' trasmettere prima di ricevere ulteriori permessi. [Page 4] September 1981 Protocollo di Controllo della Trasmissione Introduzione Multiplexing: Per permettere a molti processi di un singolo host di usare i mezzi di comunicazione simultaneamente, il TCP fornisce un insieme di indirizzi o porte all'interno di ogni host. Concatenato con la rete e l'indirizzi host dal layer di comunicazione di internet, questo forma un socket. Un paio di socket identificano unicamente ogni connessione. Cioe', un socket puo' essere usato simultaneamente in connessioni multiple. L'assegnazione delle porte ai processi e' gestita indipendetemente da ogni Host. Tuttavia, risulta utile associare i processi usati frequentemente (ad esempio, un logger o un servizio di timesharing) a socket fissi che sono noti alla gente. Questi servizi possono poi essere acceduti attraverso gli indirizzi conosciuti. Il stabilimento e l'assegnazione dell'indirizzo della porta di altri processi puo' includere meccanismi piu' dinamici. Connessioni: I meccanismi di affidabilita' e controllo del flusso descritti sopra richiedono che i TCP inizializzino e mantengano certi stati di informazioni per ogni flusso di dati. La combinazione di questa informazione, includendo i socket, sequence number, e dimensioni delle window, e' chiamata connessione. Ogni connessione e' specificata unicamente da un accoppiamento di socket che identificano i due lati relativi. Quando due processi desiderano comunicare, i loro TCP devono prima stabilire una connessione (inizializzando lo stato di informazione su ogni lato). Quando la loro comunicazione e' completa, la connessione e' terminata o chiusa per liberare le risorse per altri usi. Poiche' le connessioni devono essere stabilite tra host sconosciuti attraverso un sistema internet di comunicazione sconosciuto, un meccanismo di handshake con sequence number clock-based, e' usato al fine di evitare inizializzazioni di connessioni errate. Precedenza e Sicurezza: Gli utenti del TCP possono indicare la sicurezza e la precedenza delle loro comunicazioni. Le disposizioni sono create con valori di default per usarle quando queste caratteristiche non sono necessarie. [Page 5] September 1981 Protocollo di Controllo della Trasmissione [Page 6] September 1981 Protocollo di Controlloo della Trasmissione 2. FILOSOFIA 2.1. Elementi di un Sistema Interconnesso L'ambiente di interconnessione consiste in host collegati a reti che sono collegati attraverso gateway. Qui viene supposto che le reti possano essere reti locali (ad esempio, l'ETHERNET) o reti piu' ampie (ad esempio, ARPANET), ma in ogni caso sono basate sulla tecnologia di commutazione del pacchetto. Gli agenti attivi che producono e consumano messaggi sono processi. Vari livelli di protocolli nella rete, gateway, e host supportano un interprocesso del sistema di comunicazione che fornisce un flussi di dati a due-sensi su un connessione logica tra le porte dei processi. Il termine pacchetto e' qui usato principalmente per indicare i dati di una transizione tra un host e la sua rete. Il formato dei blocchi di dati scambiati nella rete non ci riguardera' piu' di tanto. Gli host sono computer collegati alla rete, e dal punto di vista della rete di comunicazione, sono la sorgente e la destinazione dei pacchetti. I processi sono visti come l'elemento attivo in un computer host (in concordanza con la comune e giusta definizione che un processo e' un programma in esecuzione). Persino i terminali e i file o altri dispositivi di I/O sono visti come comunicanti l'uno con l'altro attraverso l'uso di processi. In questo modo, tutta la comunicazione e' vista come una comunicazione di inter-processi. Poiche' un processo puo' avere bisogno di distinguere tra i parecchi flussi di comunicazione se stesso e un altro processo (o processi), immaginiamo che ogni processo abbia un numero di porta attraverso il quale esso comunica con la porta dell'altro processo. 2.2 Modello di Funzionamento I processi trasmettono dati chimando il TCP e passandogli buffer di dati come argomenti. Il TCP impacchetta i dati da questi buffer in segmenti e richiama il modulo internet per trasmettere ogni segmento alla destinazione TCP. Il TCP ricevente sposta i dati da segmenti ai buffer dell'utente ricevente e informa l'utente della ricezione. Il TCP include informazioni di controllo nel segmento che usano per assicurare un affidabile ordine di trasmissione dei dati. Il modello della comunicazione internet e' che ci sia un modulo di protocollo internet associato a ogni TCP che fornisce una interfaccia alla rete locale. Questo modulo internet impacchetta i segmenti TCP dentro datagrammi internet e instrada questi datagrammi al modulo internet di destinazione o al gateway intermediario. Per trasmettere il datagramma attraverso la rete locale, esso e' racchiuso in un pacchetto della rete locale. La commutazione di pacchetto puo' effettuare un ulteriore impacchet- tamento, frammentazione, o altre operazioni per realizzare la spedi- [Page 7] September 1981 Protocollo di Controllo della Trasmissione Filosofia zione del pacchetto locale al modulo internet destinarario. Al gateway tra le reti, il datagramma internet e' 'scartato' (unwrap- ped) dal suo pacchetto locale e viene esaminato al fine di determina- re attraverso quale rete il datagramma internet deve continuare il proprio viaggio. Il datagramma internet e' poi "incartato" (wrapped) in un pacchetto locale adatto alla prossima rete e instradato al prossimo gateway, o alla destinazione finale. Ad un gateway e' permesso di dividere il datagramma internet in fram- menti piu' piccoli se necessario per la trasmissione attraverso la prossima rete. Per fare questo, il gateway crea un insieme di datag- rammi internet; ogni dei quali trasporta un frammento. I frammenti possono essere ulteriormente divisi in frammenti piu' piccoli ai gateway seguenti. Il formato del frammento del datagramma internet e' progettato in modo che il modulo internet ricevente possa riass- emblare i frammenti nei datagrammi internet. Il modulo internet di destinazione spacchetta il segmento dal datagramma (dopo aver riassemblato il datagramma, se necessario) e lo passa al TCP di destinazione. Questo semplice modello di funzionamento approssima molti dettagli. Una caratteristica importante e' il tipo di servizio. Questa fornisce informazioni al gateway (o al modulo internet) per guidarlo nella selezione dei parametri di servizio che deve usare per attraversare la prossima rete. La precedenza dei datagrammi e' inclusa nel tipo di servizio. I datagrammi possono anche trasportare infomazioni di sicurezza per permettere a host e gateway che operano negli ambienti sicuri multilivelli di segregare propriamente i datagrammi per considerazioni di sicurezza. 2.3. L'Ambiente Host Il TCP presuppone di essere un modulo in un sistema operativo. Gli utenti accedono al TCP analogamente a come accedono ad un file system. Il TCP puo' chiamare altre chiamate del sistema operativo, per esempio, per controllare le strutture dei dati. L'interfaccia reale alla rete e' progettata per essere controllata da un modulo del driver di dispositivo. Il TCP non chiama direttamente il dispositivo driver direttamente, ma piuttosto chiama il modulo internet del protocollo dei datagrammi che puo' a sua volta chiamare il driver del dispositivo. Il meccanismo del TCP non preclude un'implementazione del TCP in un processore front-end. Tuttavia, in tale implementazione, un protocollo host-a-host deve fornire la funzionalitą per sostenere il tipo di interfaccia di TCP-user descritto in questo documento. [Page 8] September 1981 Protocollo di Controllo della Trasmissione Filosofia 2.4. Interfacce L'interfaccia TCP/utente prevede chiamate fatte dall'utente al TCP per APRIRE o CHIUDERE una connessione, per SPEDIRE e RICEVERE dati, o per ottenere lo STATO di una connessione. Queste chiamate sono analoghe alle altre chiamate dei programmi utente al sistema operativo, per esempio, le chiamate per aprire, leggere, e chiudere un file. L'interfaccia TCP/utente fornisce chiamate per spedire e ricevere datagrammi indirizzati al modulo TCP a host in qualsiasi parte del sistema internet. Queste chiamate hanno parametri per passare l'indirizzo, il tipo di servizio, la precedenza, la sicurezza, e altre informazini di controllo. 2.5. Relazione ad Altri Protocolli Il diagramma seguente illustra il posto del TCP nella gerarchia dei protocolli: +------+ +-----+ +-----+ +-----+ |Telnet| | FTP | |Voice| ... | | Livello Appliczione +------+ +-----+ +-----+ +-----+ | | | | +-----+ +-----+ +-----+ | TCP | | RTP | ... | | Livello Host +-----+ +-----+ +-----+ | | | +-------------------------------+ | Protocollo Internet & ICMP | Livello Gateway +-------------------------------+ | +---------------------------+ | Protocollo Rete Locale | Livello Rete +---------------------------+ Relazione tra Protocolli Figura 2. E' previsto che il TCP possa supportare efficientemente i protocolli di livello superiore. Dovrebbe essere semplice interfacciare protocolli superiori come il Telnet di ARPANET o l'AUTODIN II THP al TCP. 2.6. Comunicazione Affidabile Un flusso di dati spedito in una connessione TCP e' consegnato in modo sicuro e ordinato alla destinazione. [Page 9] September 1981 Protocollo di Controllo della Trasmissione Filosofia La tramissione e' fatta in modo affidabile attraverso l'uso di sequence number e relativi acknowledgmnet. Concettualmente, ogni otteto di dati e' assegnato a un sequence number. Il sequence number del primo otteto di dati in un segmento e' trasmesso con quel segme- nento ed e' chiamato il sequence number del segmento. I segmenti trasportano anche un acknowledgment number che e' il sequence number del prossimo otteto di dati previsto dalla trasmissione in modo inverso. Quando il TCP trasmette un segmento contente dati, mette una copia nella coda di ritrasmissione e fa partire un timer; quando l'acknowledgment per il dato e' ricevuto, il segmento e' cancellato dalla coda. Se l'acknowledgmnet non e' ricevuto prima che il timer termini, il segmento viene ritrasmesso. Un acknowledgmnet (ACK) dal TCP non garantisce che i dati sono stati trasportati all'utente finale, ma solo che il TCP ricevente ha preso la responsabilita' di farlo. Per gestire il flusso di dati tra i TCP, e' impiegato un meccanismo di controllo del flusso. Il TCP ricevente restituisce una window al TCP mittente. Questa window sequence number di otteti, par- tendo dal acknowledgment number, che il TCP ricevente sta attualmente preparando a ricevere. 2.7. Stabilimento della Connessione e Cancellazione Per identificare i flussi di dati distinti che il TCP puo' gestire, il TCP fornisce una porta di identificazione. Poiche' le porte di indentificazioni sono selezionate indipendentemente da ogni TCP possono anche non essere uniche. Per fornire degli indirizzi unici entro ogni TCP, noi concateniamo un indirizzo internet con una porta di identificazione per generare un socket che sara' unico in tutta la rete. Una connessione e' completamente identificata dall'accoppiamento dei socket alle estremita'. Un socket locale puo' partecipare a molte connessioni a differenti socket remoti. Una connessione puo' essere usata per trasportare dati in entrambe le direzioni, cioe', si dice che e' "full duplex". I TCP sono liberi di associare le porte con i processi che tuttavia loro scelgono. Tuttavia, parecchi concetti di base sono necessari in ogni implementazione. Ci devono essere dei socket noti, ai quali il TCP associa solo gli "appropriati" processi in qualche modo. Noi prevediamo che i processi possano "possedere" porte, e che i processi possono iniziare delle connessione solo sulle porte che possiedono. (I mezzi per implementare una proprieta', e' una richiesta locale, ma prevediamo un 'Request Port user command', o un metodo per allocare unicamente un gruppo di porte a un dato processo, ad esempio, asso- ciando i bit di ordine alto di un nome di porta con un dato processo.) Una connessione e' specificata nella chiamata OPEN attraverso la porta locale e argomenti sconosciuti del socket. In cambio, il TCP fornisce un (piccolo) collegamento attraverso il quale l'utente si [Page 10] September 1981 Protocollo di Controllo della Trasmissione Filosofia riferisce alla connessione nelle chiamate successive. Ci sono parec- chie cose che devono essere ricordare riguardo a una connessione. Per immagazzinare queste informazioni immaginiamo che ci sia una struttura di dati chiamata Controllo di Trasmissione dei Blocchi (Transmission Control Block, TCB). Una strategia di implementazione farebbe il nome locale del collegamento un puntatore al TCB per questo collegamento. La chiamata OPEN specifica inoltre se il stabilimento della connessione deve essere ripetuto, oppure aspettato passivamente. Una richiesta OPEN passiva significa che il processo vuole accettare richieste di connessione entranti piuttosto che tentare di iniziare una connessione. Spesso il processo richiedente una OPEN passiva accettera' richieste di connessioni da ogni richiedente. In questo caso un socket remotocon tutti gli zeri e' usato per denotare un socket non specificato. I socket remoti non specificati sono ammessi solo nelle OPEN passive. Un processo servente che desidera fornire servizi a altri processi sconosciuti dovrebbe rchiedere una richiesta d iOPEN passiva con un socket remoto non specificato. Poi una connessione puo' essere fatta con qualsiasi processo che richieda connessione a questo socket locale. Sarebbe di aiuto se questo socket locale fosse noto al fine di essere associato con questo servizio. I socket noti sono un meccanismo conveniente per l'associazione a priori di un socket con un servizio standard. Per esempio, il pro- cesso "Servente-Telnet" e' permanentemente assegnato a un socket particolare, e altri socket sono riservati per il Trasferimento di File (FTP), Remote Job Entry, Text Generator, Echoer, e processi Sink (gli ultimi tre sono per test). Un indirizzo del socket potrebbe essere riservato a un servizio di "Look-Up" il quale restituirebbe il socket specifico a cui un servizio recentemente creato sarebbe fornito. Il concetto di socket noti e' parte delle specifiche del TCP, ma l'assegnamento dei socket a servizi e' fuori da queste spe- cifiche. (Vedi [4].) I processi possono richiedere OPEN passive e aspettare per la corri- spondente OPEN dagli altri processi ed essere informato dal TCP quando le connessioni sono state stabilite. Due processi che richiedono OPEN attive l'uno all'altro allo stesso tempo, saranno correttamente connessi. Questa flessibilita' e' fondamentale per il supporto del calcolo distribuito nel quale i componenti agiscono in modo asincrono l'uno rispetto all'altro. Ci sono due principali casi per abbinare i socket nelle OPEN locali passive e nelle OPEN remote attive. Nel primo caso, la OPEN locali passive ha completamente specificato il socket remoto. In questo caso, l'abbinamento deve essere esatto. Nel secondo caso, le OPEN locali passive hanno lasciato il socket remoto non specificato. In questo caso, qualsiasi socket remoto e' accet- tabile finche' i socket locali "sono uguali". Altre possibilita' includono parzialmente abbinamenti ristretti. [Page 11] September 1981 Protocollo di Controllo della Trasmissione Filosofia Se ci sono parecchie OPEN passive in corso (registrate nei TCB) con lo stesso socket locale, una OPEN remota attiva sara' abbinata a un TCB con il specifico socket remoto nella OPEN remota attiva, se un TCB esiste, prima di selezionare un TCB con un socket remoto non specificato. Le procedure per stabilire una connessione utilizzano il flag (SYN) di sincronizzazione e include lo scambio di tre messaggi. Questo scambio e' noto come il tree-way hand shake [3]. Una connessione e' iniziata attraverso l'arrivo contemporaneo di segmenti contenenti un SYN e ogni entry del TCB in attesa e' creata dal comando utente OPEN. L'abbinamento di socket locali e remoti determina quando una connessione e' iniziata. La connessione diventa "stabilita" quando i numeri di sequenza sono sincronizzati in entrambe le direzioni. Anche la cancellazione di una connessione include lo scambio di seg- menti, in questo caso trasportando il flag di controllo FIN. 2.8. Trasmissione di Dati I dati che fluiscono in una connessione possono essere pensati come un flusso di otteti. L'utente mittente indica in ogni chiamata SEND se i dati in quella chiamata (e ogni chiamata precedente) dovrebbero essere pushati immediatamente attraverso l'utente ricevente impostando il flag PUSH. Al TCP mittente e' permesso raccogliere i dati dall'user mittente e spedire questi dati in segmenti a sua convenienza, finche' la fun- zione push e' segnalata, poi tutti i dati non spediti devono essere spediti. Quando un TCP ricevente vede il flag PUSH, esso non deve aspettare altri dati dal TCP di tramissione prima di passare i dati al processo di ricezione. Non c'e' una relazione necessaria tra la funzione push e i limiti del segmento. I dati in ogni particolare segmento possono essere il risultato di una singola chiamata SEND, interamente o in parte, oppure di chiamate SEND multiple. Lo scopo della funzione push e il flag PUSH e' si spingere i dati dall'utente mittente all'utente ricevente. Esso non fornisce un ser- vizio di registrazione. C'e' un accoppiamento tra la funzione push e l'uso di buffer di dati che attraversano l'interfaccia TCP/utente. Ogni volta che il flag PUSH e' associato con i dati posti nel buffer dell'utente ricevente, il buffer e' restituito all'utente per l'elaborazione anche se il buffer non e' riempito. Se i dati che arrivano riempiono il buffer dell'utente prima che una funzione PUSH sia effettuata, i dati sono passati all'utente in unita' della dimensione del buffer. Il TCP fornisce inoltre un mezzo per comunicare a il ricevente dei dati che in qualche punto piu' avanti nel flusso di dati [Page 12] September 1981 Protocollo di Controllo della Trasmissione Filosofia che sta attualmente leggendo ci sono dei dati urgenti. Il TCP non tenta di definire in modo specifico cosa l'user faccia uan volta avvertito che ci sono dei dati urgenti , ma la cosa generale e' che il processo ricevente elaboreraa' velocemente i dati urgenti. 2.9. Precedenza e Sicurezza Il TCP fa uso tipo di servizio del protocollo internet e opzioni di sicurezza per fornire precedenza e sicurezza a una connessione di base agli utenti del TCP. Non tutti i moduli del TCP funzioneranno necessariamente in un ambiente di sicurezza a multilivello; alcuni possono essere limitati a solo uso non classificato, e altri possono funzionare solo ad un livello di sicurezza e compartimento. Conse- guentemente, alcune implementazioni del TCP e servizi agli utenti possono essere limitati a un sottoinsieme di casi di sicurezza a multilivelli. I moduli TCP che funzionano in un ambiente di sicurezza a multilivello devono propriamente marcare i segmenti uscenti con la sicurezza, com- partimento, e la precedenza. Tali moduli TCP forniscono anche ai loro utenti o protocolli di livello superiore come Telnet o THP una inter- faccia per permettere loro di specificare il livello desiderato di sicurezza, compartimento, e precedenza di connessioni. 2.10. Principio di Robustezza Le implementazioni del TCP seguono un principio generale di robustezza: essere conservativi in quello che fai, essere liberali in cio' che tu accetti dagli altri. [Page 13] September 1981 Protocollo di Controllo della Trasmissione [Page 14] September 1981 Protocollo di Controllo Della Trasmissione 3. SPECIFICHE DI FUNZIONAMENTO 3.1. Formato dell'Intestazione I segmenti del TCP sono spediti come datagrammi di internet. L'intestazione del Protocollo Internet trasporta parecchi campi di informazione, includendo gli indirizzi del mittente e e di destinazione [2]. Un header TCP segue l'header internet, fornendo specifiche informazioni al protocollo TCP. Questa divisione tiene conto dell'esistenza di altri livelli di protocollo nell'host diversi dal TCP. Formato dell'intestazione del TCP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Porta Sorgente | Porta di Destinazione | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Riservato |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Puntatore di Urgenza | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opzioni | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dati | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Formato dell'intestazione del TCP Nota che ogni segno rappresenta la posizione di un bit. Figura 3. Porta Sorgente: 16 bit Il numero della porta sorgente. Porta di Destinazione: 16 bit Il numero di porta della destinazione. [Page 15] September 1981 Protocollo di Controllo della Trasmissione Specifiche del Funzionamento Sequence Number: 32 bit Il sequence number dei primi otteti di dati in questo segmento (eccetto quando il SYN e' presente). Se il SYN e' presente il sequence number e' il numero iniziale della sequenza (initial sequence number, ISN) e il primo otteti di dati e' ISN+1. Acknowledgment Number: 32 bit Se il bit di controllo ACK e' settato questo campo contiene il valore del prossimo sequence number che il mittente del segmento prevede di ricevere. Una volta che la connessione e' stabilita questo viene sempre trasmesso. Data Offset: 4 bit Il numero di 32 bit word nell'intestazione del TCP. Questo indica dove i dati iniziano. L'intestazione del TCP (se uno include opzioni) e' un numero integrale di tipo long di 32 bit. Riservato: 6 bit Riservato per usi futuri. Deve essere zero. Bit di Controllo: 6 bit (da sinistra a destra): URG: Un flag che indica che il valore all'interno del campo Urgent e' valido ACK: Un flag che indica che il valore all'interno del campo ACK e' valido PSH: Funzione Push RST: Resetta la connessione SYN: Sincronizza i numeri di sequenza FIN: Nessun ulteriore dato dal mittente Window: 16 bit Il numero di otteti di dati inizianti con quello indicato nel campo acknowledgment che il mittente di questo segmento e' disposto ad accettare. Checksum: 16 bit Il campo del checksum sono 16 bit. Se il segmento contiene un numero dispari di intestazioni e di otteti di testo da essere sottoposti al checksum, l'utimo otteto e' riempito a destra di zeri per formare una word di 16 bit per fini del checksum. Mentre calcola il checksum, il campo checksum sostituisce se stesso con degli zeri. Il checksum copre anche una pseudo-intestazione di 96 bit concet- [Page 16] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento tualmente prefissata all'intestazione del TCP. Questa pseudo-inte- stazione contiene l'Indirizzo Sorgente, l'Indirizzo Destinatario, il Protocollo, e la lunghezza del TCP. Questo da' al TCP la protezione contro segmenti misrouted. Questa informazione e' trasportata nel Protocollo Internet ed e' trasferita attraverso l'interfaccia TCP/Rete negli argomenti o risultato di una chiamata attraverso il TCP sull'IP. +--------+--------+--------+--------+ | Indirizzo Sorgente | +--------+--------+--------+--------+ | Indirizzo di Destinazione | +--------+--------+--------+--------+ | zero | PTCL | Dimensione TCP | +--------+--------+--------+--------+ La Dimensione del TCP e' la dimensione dell'intestazione del TCP piu' la dimensione dei dati in otteti (questa non e' una quantita' esplicitamente trasmessa, ma e' calcolata), ed esso non conta i 12 otteti della pseudo-intestazione. Puntatori di Urgenza: 16 bit Questo campo comunica l'attuale valore del puntatore urgent come un offset positivo dal numero di sequenza in questo segmento. Il puntatore urgent punta al numero di sequenza dell'otteto seguendo i dati urgenti. Questo campo e' solo interpretato in segmenti con il bit di controllo URG impostato. Opzioni: variabile Le opzioni possono occupare spazio alla fine dell'intestazione del TCP e per quanto riguarda la dimensione sono multipli di 8 bit. Tutte le opzioni sono incluse nel checksum. Una opzione puo' iniziare alle fine di un otteto. Ci sono due casi per il formato di una opzione: Caso 1: Un singolo otteto di tipo-di-opzione. Caso 2: Un otteto di tipo-di-opzione, un otteto della lunghezza- di-opzione, e gli otteti attuali di opzione-di-dati. La opzione-di-lunghezza conta i due otteti del tipo-di-opzione e della opzione-di-lunghezza cosi' come gli otteti opzione-di-dati. Nota che la lista delle opzioni puo' essere piu' corta di quanto potrebbe esserlo il campo data offset. Il contenuto dell'intestazione oltre ad avere l'opzione Fine-delle-Opzioni deve essere riempito (ad esempio, con degli zeri). Un TCP deve eseguire tutte le opzioni. [Page 17] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Le opzioni attualmente definite includono (tipo indicato in otteti): Tipo Lunghezza Significato ---- ------ ------- 0 - Fine della lista delle opzioni. 1 - No-Operation. 2 4 Dimensione Massima del Segmento. Definizione Specifiche delle Opzioni Fine della Lista delle Opzioni +--------+ |00000000| +--------+ Tipo=0 Questo codice dell'opzione indica la fine della lista delle opzioni. Questo puo' non coincidere con la fine dell'intestazione del TCP secondo il campo Data Offset. Questo e' usato alla fine di tutte le opzioni, non alla fine di ogni singola opzione, e necessita di essere usato solo se la fine delle opzioni non coinciderebbe con la fine dell'intestazione del TCP. No-Operation +--------+ |00000001| +--------+ Tipo=1 Questo codice di opzione puo' essere usato tra le opzioni, per esempio, per allineare una sottosequenza di opzioni al limite di una word. Non si assicura che i mittenti usaranno questa opzione, cosi' i riceventi devono preparasi a processare le opzioni anche se non iniziano al limite di una word. Dimensione Massima del Segmento +--------+--------+---------+--------+ |00000010|00000100| dim max seg | +--------+--------+---------+--------+ Tipo=2 Lunghezza=4 [Page 18] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Opzione della Dimensione Massima del Segmento: 16 bit Se questa opzione e' presente, allora essa comunica la dimensione massima del segmento ricevuta al TCP che spedisce questo segmento. Questo campo deve essere spedito solo nella richiesta iniziale di connessione (ad esempio, nei segmento dove il bit di controllo SYN e' impostato). Se questa opzione non e' usata, qualsiasi dimensione del segmento e' permessa. Padding: variabile Il padding dell'intestazione del TCP e' usata per assicurare che l'intestazione del TCP finisca e i dati inizino al limite di 32 bit 3.2. Terminologia Prima di discutere in modo piu' approfondito il funzionamento del TCP, abbiamo bisogno di introdurre una certa terminologia dettagliata. Il La manutenzione di una connessione TCP richiede la memorizzazione di parecchie variabili. Abbiamo detto che queste variabili sono immagazzinate in un registro della connessione chiamato Blocco del Controllo della Trasmissione o TCB. Tra le variabili memorizzate nel TCB ci sono i numeri del socket locale e remoto, la sicurezza e la precedenza della connessione, puntatori ai buffer dell'utente mittente e ricevente, puntatori alla coda di ritrasmissione e al segmento corrente. In piu' parecchie variabili relative ai sequence number del mittente e del ricevente sono memorizzate nel TCB. Variabili di Sequenza del Mittente SND.UNA - invia unacknowledged SND.NXT - invia il prossimo SND.WND - invia window SND.UP - invia urgent pointer SND.WL1 - segmento del sequence number usato per l'utimo aggiornamento della window SND.WL2 - segmento del acknowledgment number usato per per l'ultimo aggiornamento della window ISS - Sequence Number iniziale inviato Variabili di Sequenza del Ricevente RCV.NXT - ricevi il prossimo RCV.WND - ricevi window RCV.UP - ricevi urgent pointer IRS - sequence number iniziale ricevuto [Page 19] September 1981 Protocollo di Controllo della Trasmissione Specifiche Funzionali Il diagramma seguente puo' aiutare ad associare alcune di queste variabili al sequence space. Sequence Space Trasmesso 1 2 3 4 ----------|----------|----------|---------- SND.UNA SND.NXT SND.UNA +SND.WND 1 - vecchi sequence number che sono stati riconosciuti 2 - sequence number di dati non riconosciuti 3 - sequence number ammessi per una nuova trasmissione di dati 4 - futuri sequence number che non sono ancora ammessi Sequence Space Trasmesso Figura 4. La window trasmessa e' la porzione del sequence space etichettata col numero 3 nella figura 4. Sequence Space del Ricevente 1 2 3 ----------|----------|---------- RCV.NXT RCV.NXT +RCV.WND 1 - vecchi sequence number che sono stati riconosciuti 2 - sequence number ammessi per la nuova ricezione 3 - futuri sequence number che non sono ancora ammessi Sequence Space del Ricevente Figura 5. La window ricevuta e' la porzione del sequence space etichettata col numero 2 nella figura 5. Ci sono anche altre variabili usate frequentemente nelle discussioni che prendono i loro valori dai campi del segmento corrente. [Page 20] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Variabili del Segmento Corrente SEG.SEQ - segmento del sequence number SEG.ACK - segmento dell'acknowledgmemt number SEG.LEN - segmento della lunghezza SEG.WND - segmento della window SEG.UP - segmento del urgent pointer SEG.PRC - segmento del valore di precedenza Una connessione progredisce attraverso una serie di stati durante la sua esistenza. Gli stati sono: LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, e lo stato immaginario CLOSED. CLOSED e' immaginario perche' rappresenta lo stato quando non ci sono TCB, e di conseguennza, nessuna connessione. In breve, il significato di questi stati e': LISTEN - Rappresenta lo stato di attesa per una connessione da qualisiasi TCP e porta remota. SYN-SENT - rappresenta lo stato di attesa per la corrispondenza della connessione richiesta dopo avere spedito una richiesta di connessione. SYN-RECEIVED - rapperesenta lo stato per l'attesa per la conferma di una connessione riconosciuta dopo avere ricevuto e spedito un richiesta di connessione. ESTABLISHED - rappresenta una connessione aperta, i dati ricevuti possono essere spediti all'utente. E' lo stato normale durante la fase di trasferimento. FIN-WAIT-1 - rappresenta l'attesa per la richiesta di conclusione della connessione dal TCP remoto, o il riconoscimento di una richiesta di connessione precedentemente spedita. FIN-WAIT-2 - rappresenta lo stato di attesa per la conclusione della connessione dal TCP remoto. CLOSE-WAIT - rappresenta l'attesa della conclusione di una connessione richiesta dall'utente locale. CLOSING - rappresenta l'attesa per il riconoscimento dell'avvenuta terminazione della conclusione dal TCP remote. LAST-ACK - rappresenta l'attesa per il riconoscimento della richiesta di conclusione della connessione precedentemente spedita al TCP remoto. (il quale include il riconoscimento della sua richiesta di terminazione della connessione). [Page 21] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento TIME-WAIT - rappresenta l'attesa che passi abbastanza tempo per essere sicuri che il TCP remoto abbia ricevuto la conferma della sua richiesta di conclusione della connessione. CLOSED - non rappresenta alcun stato. Una connessione TCP progredisce da un stato all'altro in risposta a degli eventi. Gli eventi sono le chiamate utenti, OPEN, SEND, RECEIVE, CLOSE, ABORT e STATUS; i segmenti arrivo, particolarmenti quelli contenenti i flag SYN, ACK, RST e FIN; e i timeout. Il diagramma di stato nella figura 6 illustra solo i cambiamento di stato, insieme agli eventi che lo hanno causato e le azioni risultanti, ma non si riferisce a errori dovuti alle condizioni o alle azioni che non sono connesse con il cambiamento di stato. In una prossima sezione, maggiori dettagli saranno forniti riguardo alla rezione del TCP a questi eventi. NOTA BENE: questo diagramma e' solo un sommario e non deve essere preso come descrizione totale [Page 22] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento +---------+ ---------\ OPEN attiva | CLOSED | \ ----------- +---------+<---------\ \ crea TCB | ^ \ \ snd SYN OPEN passiva | | CLOSE \ \ ------------ | | ---------- \ \ crea TCB | | cancella TCB \ \ V | \ \ +---------+ CLOSE | \ | LISTEN | ---------- | | +---------+ cancella TCB | | rcv SYN | | SEND | | ----------- | | ------- | V +---------+ snd SYN,ACK / \ snd SYN +---------+ | |<----------------- ------------------>| | | SYN | rcv SYN | SYN | | RCVD |<-----------------------------------------------| SENT | | | snd ACK | | | |------------------ -------------------| | +---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+ | -------------- | | ----------- | x | | snd ACK | V V | CLOSE +---------+ | ------- | ESTAB | | snd FIN +---------+ | CLOSE | | rcv FIN V ------- | | ------- +---------+ snd FIN / \ snd ACK +---------+ | FIN |<----------------- ------------------>| CLOSE | | WAIT-1 |------------------ | WAIT | +---------+ rcv FIN \ +---------+ | rcv ACK of FIN ------- | CLOSE | | -------------- snd ACK | ------- | V x V snd FIN V +---------+ +---------+ +---------+ |FINWAIT-2| | CLOSING | | LAST-ACK| +---------+ +---------+ +---------+ | rcv ACK of FIN | rcv ACK of FIN | | rcv FIN -------------- | Timeout=2MSL -------------- | | ------- x V ------------ x V \ snd ACK +---------+cancella TCB +---------+ ------------------------>|TIME WAIT|------------------>| CLOSED | +---------+ +---------+ Diagramma dello Stato di una Connessione TCP Figura 6. [Page 23] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento 3.3. Sequence Number Una nota fondamentale nella progettazione e' che ogni otteto di dati spedito sopra una connessione TCP ha un sequence number. Poiche' ogni otteto e' consecutivo, ognuno di essi puo' essere riconosciuto. Il meccanismo di riconoscimento adottato e' cumulativo cosi' un riconoscimento del sequence number X indica che tutti gli otteti da, ma non includendo X sono stati ricevuti. Questo meccanismo permette la straight-forward duplicate detection in presenza di una ritrasmissione. La numerazione degli otteti entro il segmento il quale e' il primo otteto di dati che segue l'intestazione e quello numerato piu' basso, e gli otteti seguenti sono numerati consecutivamente. E' essenziale ricordare che l'attuale spazio dei sequence number e' finito, anche se veramente grande. Questo spazio parte da 0 fino a 2**32 - 1. Poiche' lo spazio e' finito, tutte le operazioni aritmetiche con i sequence number devono essere effettuate con modulo 2**32. Questa aritmetica senza segno mantiene la relazione dei sequence number che ciclano ancora da 0 a 2**32 -1. Ci sono alcuni accorgimento per il calcolo aritmetico a modulo, dovrebbe essere presa la stessa cura della programmazione in relazione a questi valori. Il simbolo "=<" significa "minore o uguale" (modulo 2**32). Il tipico tipo di comparazione di sequence number che il TCP effettua deve includere: (a) Determinare che un acknowledgment si riferisca a qualche sequence number spedito ma non ancora riconosciuto. (b) Determinare che tutti i sequence number occupati da un segmento siano stati riconosciuti (ad esempio, per rimuovere il segmento dalla coda di ritrasmissione). (c) Determinare che i segmenti in arrivo contengano i sequence number aspettati (ad esempio, un segmento che vada al di fuori della window ricevuta). [Page 24] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento In risposta alla spedizione di dati il TCP ricevera' delle conferme. I seguenti confronti sono necessari per calcolare gli acknowledgement. SND.UNA = sequence number non confermato piu' vecchio SND.NXT = il prossimo sequence number da spedire SEG.ACK = acknowledgement dal TCP ricevente (il prossimo sequence number previsto dal TCP ricevente) SEG.SEQ = primo sequence number di un segmento SEG.LEN = il numero di otteti occupati dai dati nel segmento (includendo il SYN e il FIN) SEG.SEQ+SEG.LEN-1 = ultimo sequence number di un segmento Un nuovo acknowledgment (chiameto un "ack accettabile"), e' uno per il quale l'ineguaglianza sotto tiene: SND.UNA < SEG.ACK =< SND.NXT Un segmento sulla coda di ritrasmissione e' pienamente riconosciuto se la somma del suoi sequence number o della lunghezza e' minore o uguale al valore dell'acknowledgement nel semgnento entrante. Quando i dati sono ricevuti le seguenti comparazioni sono necessarie: RCV.NXT = il prossimo sequence number previsto per i segmenti in arrivo, e' il limite di sinistra o piu' basso della window ricevuta. RCV.NXT+RCV.WND-1 = ultimo sequence number previsto per un segmento in arrivo, e' la destra oppure il limite superiore della window ricevuta. SEG.SEQ = primo sequence number occupato dal segmento entrante SEG.SEQ+SEG.LEN-1 = ultimo sequence number occupato dal segmento entrante. Un segmento e' giudicato per occupare una porzione del sequence space valido ricevuto se RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND oppure RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND [Page 25] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento La prima parte di questa verifica controlla per vedere se la parte iniziale del segmento rientra nella window, la seconda parte della verifica controlla per vedere se la fine del segmento rientra nella window; se il segmento passa una parte della verifica esso contiene dati nella window. Attualmente, e' un po' piu' complicato di cosi'. Due a zero window e segmenti di lunghezza zero. abbiamo quattro casi per l'accettazione di un segmento entrante: Segmento Window Verifica Lunghezza Ricevuta ------- ------- ------------------------------------------- 0 0 SEG.SEQ = RCV.NXT 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >0 0 non accettabile >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND o RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND Nota che quando la window ricevuta e' zero, nessuno segmento dovrebbe essere accettabile accetto i segmenti ACK. In questo modo, e' possibile per un TCP di mantenere a zero le window ricevute mentre sta trasmettendo dati e sta ricevendo ACK. Tuttavia, anche quando le window ricevute sono zero, un TCP deve processare i campi RST e URG di tutti i segmenti in arrivo. Abbiamo appreso il vantaggio dello schema di numerazione per proteggere anche certe informazioni di controllo. Questo e' realizzato implicitamente attraverso l'inclusione di alcuni flag nel sequence space cosi' loro possono essere ritrasmessi e riconosciuti senza confusione (cioe', una e una sola copia di controllo sara' elaborata). Le informazioni di controllo non sono trasportate fisicamente dallo spazio del segmento di dati. Di conseguenza, dobbiamo adottare l'assegnamento implicito di sequence number per il controllo. Il SYN e il FIN sono gli unici controlli che richiedono questa protezione, e quei controlli sono usati solo per aprire e chiudere una connessione. Per lo scopo dei sequence number, il SYN e' pensato per presentarsi prima che gli attuali otteti di dati del segmento nel quale si presenta, mentre il FIN e' pensato per presentarsi dopo che gli ultimi otteti dei dati attuali in un segmento nel quale si trova. La lunghezza del segmento (SEG.LEN) include entrambi i sequence space occupanti i controlli. Quando un SYN e' presente allora il SEG.SEQ e' il sequence number del SYN. [Page 26] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Selezione Iniziale dei Sequence Number Il protocollo non pone restrinzione a una connessione particolare che sta ancora usando. Una connessione e' definita da una coppia di socket. Nuove istanze di una connessione saranno riferite come incarnazioni della connessione. Il problema che si presenta da cio' e' -- "come il TCP identifica segmenti duplicati dalla incarnazione precedente della connessione?" Questo problema diventa apparente se la connessione e' aperta e chiusa in brevi successioni, o se la connessione si interrompe con perdita di dati e poi e' ristabilita. Per evitare confusione, dobbiamo evitare i segmenti provenienti da una incarnazione di una connessione, usando gli stessi sequence number i quali possono ancora essere presenti nella rete da una incarnazione precedente. Vogliamo assicurarlo, anche se il TCP crasha e perde tutte le conoscenze dei sequence number che sono stati usati. Quando una nuova connessione e' creata, un generatore inziaziale di sequence number (ISN) e' incaricato di selezionare una nuova ISN di 32 bit. Il generatore e' limitato ad un (possibilmente fittizio) orologio di 32 bit 'whose low order bit' e' incrementato approssimativamente ogni 4 microsecondi. In questo modo, l'ISN cicla approssimativamente ogni 4,55 ore. Poiche' presupponiamo che un segmento non stara' nella rete non piu' del Maximun Segment Lifetime (MSL) e il MSL e' meno di 4,55 ore, possiamo presuppore ragionevolmente che il ISN sara' unico. Per ogni connessione c'e' un sequence number del mittente e un sequence number del ricevente. Il sequence number del mittente (ISS) e' scelto attraverso i dati che trasmettono il TCP, e il sequence number del ricevente (IRS) e' deciso durante la procedura di stabilimento della connessione. Per il stabilimento o iniziazione di una connessione, i due TCP devono sincronizzare l'uno con l'altro i loro sequence number. Questo e' fatto attraverso lo scambio di segmenti di stabilimento della connessione che trasportano un bit di controllo chiamato "SYN" (per la sincronizzazione) e i sequence number iniziali. Per abbreviare, i segmenti che trasportano il bit SYN sono anche chiamati "SYN". Quindi la soluzione richiede un meccanismo adatto per decidere un sequence number iniziale e l'implicazione di un handshake per scambiare gli ISN. La sincronizzazione richiede che ogni lato spedisca il suo sequence number iniziale e di ricevere una conferma di questo in un riconoscimento da parte dell'altro lato. Ogni lato deve inoltre riceve il sequence number iniziale dell'altro lato e spedire una conferma. 1) A --> B SYN il mio sequence number e' X 2) A <-- B ACK il tuo sequence number e' X 3) A <-- B SYN il mio sequence number e' Y 4) A --> B ACK il tuo sequence number e' Y [Page 27] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Poiche' i punti 2 e 3 sono combinati in un singolo messaggio, questo e' chiamata il three way (o three message) handshake. Un three way handshake e' necessario perche' i sequence number non sono legati a un orologio globale della rete, e i TCP possono avere differenti meccanismi per decidere gli ISN. Il ricevente del primo SYN non ha modo di sapere se il segmento era uno in ritardo o no, a meno che si ricordi l'ultimo sequence number usato nella connessione (che non e' sempre possibile), e cosi' deve chiedere al mittene di verificare questo SYN. Il three way handshake e i vantaggi di uno schema clock-driven sono discussi nel [3]. Sapere Quanto Tenerlo Abbastanza Per essere sicuri che il TCP non crei un segmento che trasporti un sequence number il quale possa essere duplicato da un vecchio segmento rimasto nella rete, il TCP deve ternelo abbastanza per un maximun segment lifetime (MSL) prima di assegnare qualsiasi sequence number all'inizio o riprendendo da un crash nel quale la memoria dei sequence number ando' persa. Per questa particolarita' e' impostato a due minuti. Questa e' una scelta di progettazione, e puo' essere cambiata se l'esperienza suggerisce che e' meglio farlo. Nota che che se un TCP e' reinizializzato in qualche senso, mantiene tuttavia la sua memoria di sequence number in uso, allora non devo attendere altro; deve solo essere sicuro di usare sequence number piu' grandi di quelli usati recentemente. Il Concetto TCP Quiet Time Questa caratteristica fornisce agli host che crashano senza mantenere alcuna conoscenza degli ultimi sequence number trasmessi in oggi connessione attiva (cioe', non chiusa) fara' ritardare l'emissione di qualsiasi segmento TCP almeno durante il Maximum Segment Lifetime (MSL) nel sistema internet di cui l'host e' parte. Nel paragrafo sotto, e' data una spiegazione di questa caratteristica. Chi implementa il TCP puo' violare la restrinzione "quiet time", ma solo col rischio che vecchi dati possano essere accettati come nuovi o nuovi dati rifiutati come vecchi duplicati da qualche ricevente nel sistema internet. Il TCP usa lo spazio dei sequence number ogni volta che un segmento e' formato e immesso nella code di output della rete dell'host mittente. La rilevazione dei duplicati e degli algoritmi di sequenza nel protocollo TCP conta sull'unione unica dei segmenti di dati in sequence space per ordinare lo spazio in serie fino al punto in cui i numeri progressivi non cicleranno con tutti i valori 2**32 prima che il segmento di dati limiti a questi sequence number e tutti che le copie duplicate dei segmenti siano "eliminati" da internt. Senza tale presupposto, a due segmenti TCP distinti possono in teoria essere [Page 28] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento asseganti gli stessi o sovrascritti sequence number, causando confusione al ricevente su quali dati sono nuovi e quali invece vecchi. Ricorda che ogni segmento e' limitato ad altrettanti sequence number poiche' ci sono otteti di dati nel segmento. In condizioni normali, i TCP tengono traccia del prossimo sequence number da emettere e di quelli precedenti in attesa di riconoscimento in modo da evitare un uso errato dei sequence number prima che siano stati riconosciuti. Questo solo non garantisce che vecchi dati duplicati siano eliminati dalla rete, cosi' il sequence space e' stato creato molto grande al fine di ridurre la probabilita' che un duplicato vagante crei problemi di arrivo. A 2 megabit/sec, ci mette 4,5 re a usare piu' di 2**32 otteti del sequence space. Poiche' con il maximum segment lifetime nella rete non e' probabile eccedere di qualche decina di secondi, cio' e' ritenuta una ampia protezione per le reti prevedibili, anche se le rate dei dati scalano a l0 megabit/sec. a 100 megabit/sec, il ciclo di tempo e' di 5,4 minuti, il quale puo' essere corto ma ancora ragionevolmente possibile. La rilevazione dei duplicati e l'algoritmo di sequenza di base nel TCP possono essere respinti, tuttavia, se un TCP mittente non ha alcuna memoria dei sequence number che ha usato l'ultima volta su una data connessione. Per esempio, i TCP dovevano iniziare tutto il collegamento con il sequence number 0, allora crashato e ripartito, un TCP puo' ri-formare una connessione precedente (possibilmente dopo la risoluzione di mezza-connessione) ed emettere pacchetti con i sequence number identici per sovrascriversi con i pacchetti ancora nella rete i quali furono emessi da una precedente incarnazione della stessa connessione. In assenza di conoscenza a riguardo dei sequence number usati in una connessione particolare, la caratteristica del TCP raccomanda che il mittente ritardi di MSL secondi prima di immettere segmenti su una connessione, per dare tempo ai segmenti della incarnazione della connessione precedente di svuotarsi dal sistema. Persino gli host che possono ricordare l'orario del giorno e usarlo per selezionare i valori dei sequence number iniziali non sono immuni a questo problema (cioe', persino se l'orario del giorno e' usato per selezionare un sequence number iniziali per ogni nuova incarnazione della connessione). Supporre, per esempio, che una connessione e' aperta partendo con sequence number S. Supporre che questa connessione non e' molto usata ed eventalmente la funzione del sequence number iniziale (ISN(t)) prende un valore uguale al sequence number, diciamo S1, dell'ultimo segmento spedito attraverso questo TCP su una connessione particolare. Ora supponiamo, che in questo istante, l'host crashi, recuperi, e stabilisca una nuova incarnazione della connessione. Il sequence number iniziale scelto e' S1 = ISN(t) -- l'ultimo sequence number usato sulla vecchia incarnazione della connessione! Se il recupero avviene [Page 29] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento abbastanza in fretta, ogni vecchio duplicato nella rete portante i sequence number nelle vicinanze di S1 puo' arrivare ed essere trattato come nuovo pacchetto dal ricevente della nuova incarnazione della connessione. Un modo per gestire questo problema e' di dare ridartare deliberatamente i segmenti per un MSL dopo il recupero da un crash, questa e' la caratteristica "quite time". Gli host che preferiscono evitare l'attesa sono esposti al possibile rischio di confondere vecchi e nuovi pacchetti a una data destinazione che ha scelto di non aspettare per il "quite time". Gli implementatori possono fornire agli utenti del TCP la capacita' di selezionare su una connessione, attraverso delle condizioni, se aspettare dopo un crash, o se implementare formalmente la "quite time" per tutte le connessioni. Ovviamente, anche quando un utente decide di "aspettare", cio' non e' necessario dopo che un host e' stato 'up' per almeno MSL secondi. Per riassumere: ogni segmento emesso occupa uno o piu' sequence number nel sequence space, i number occupati da un segmento sono "occupati" oppure "in uso" finche' MSL secondo sono passati, sul blocco d'arresto del space-time e' occupato dagli otteti dell'ultimo segmento emesso, se una nuova connessione e' avviata troppo presto e usa uno dei sequence number nell'orma del space-time dell'ultimo segmento della incarnazione della connessione precedente, ci sono sequence number che possono potezialmente sovrascrivere un'area la quale puo' causare confusione al ricevente. 3.4. Stabilendo una connessione Il three-way handshake e' la procedura usata per stabilire una connessione. Questa procedura e' normalmente iniziata da un TCP e risposta da un altro TCP. La procedura funziona anche se due TCP iniziano simultaneamente la procedura. Quando un tentativo simultaneo si verifica, ogni TCP riceve un segmento "SYN" il quale trasporta nessun acknowledgment dopo che esso ha spedito un "SYN". Naturalmente, l'arrivo di un vecchio duplicato segmento "SYN" puo' potenzialmente fare sembrare al ricevente, che una connessione simultanea sia in progresso. Un uso appropriato dei segmenti "reset" puo' chiarire quei casi Seguono parecchi esempi di iniziazioni di connessioni. Anche se questi esempi non mostrano la sincronizzazione della connessione usando segmenti data-carrying, cio' e' perfettamente legittimo, a condizione che il TCP ricevente non spedisca dati all'utente finche' esso cancella dati validi (cioe', i dati devono essere memorizzati al ricevente finche' la connessione raggiunge lo stato ESTABLISHED). Il three-way handshake riduce la possibilita' di false connessioni. E' l'esecuzione di un trade-off [Page 30] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento tra la memoria e i messaggi a fornire infomazione per questo controllo. Il piu' semplice three-way handshake e' mostrato nella figura 7 sottostante. La figura deve essere interpretata nel modo seguente. Ogni linea e' numerata per scopi di riferimento. Le freccie di destra (-->) indicano la partenza di un segmento TCP dal TCP A al TCP B, o l'arrivo di un segmento da B a A. Le freccie di sinistra (<--), indicano l'incontrario. I tre punti (...) indicano un segmento che e' ancora nella rete (ritardatario). Un "XXX" indica un segmento che e' perso o rifiutato. I commenti appaiono tra parentesi. Gli stati del TCP rappresentano gli stati DOPO la partenza o l'arrivo di un segmento (il cui contenuto e' mostrato al centro di ogni linea). I contenuti dei segmenti sono mostrati in forma abbreviata, col sequence number, flag di controllo, e il campo ACK. Altri campi come window, indirizzi, lunghezze e testo sono stati lasciati da parte per fini di chiarezza. TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> --> SYN-RECEIVED 3. ESTABLISHED <-- <-- SYN-RECEIVED 4. ESTABLISHED --> --> ESTABLISHED 5. ESTABLISHED --> --> ESTABLISHED 3-Way Handshake di Base per la Sincronizzazione della Connessione Figura 7. Nella linea 2 della figura 7, il TCP A inizia spedendo un segmento SYN indicando che esso usera' i sequence number inizianti col sequence number 100. Nella linea 3, il TCP B spedisce un SYN e l'acknowledgmnet del SYN che ha ricevuto da TCP A. Nota che il campo acknowledgmnet indica che il TCP B sta ora prevedendo di vedere la sequence 101, riconoscendo il SYN che ha occupato la sequenza 100. Alla linea 4, il TCP A risponde con un segmento vuoto, contenente un ACK per il SYN del TCP B; e alla linea 5, il TCP A spedisce qualche dato. Nota che il sequence number alla linea 5 e' lo stesso della linea 4 questo perche' l'ACK non occupa alcun sequence number space (se lo facesse, dovremo fare ACKing degli ACK!). [Page 31] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Le iniziazioni simultanee sono solo un po' piu' complesse, come e' mostrato in figura 8. Ogni TCP cicla da CLOSED a SYN-SENT a SYN-RECEIVED a ESTABLISHED. TCP A TCP B 1. CLOSED CLOSED 2. SYN-SENT --> ... 3. SYN-RECEIVED <-- <-- SYN-SENT 4. ... --> SYN-RECEIVED 5. SYN-RECEIVED --> ... 6. ESTABLISHED <-- <-- SYN-RECEIVED 7. ... --> ESTABLISHED Sincronizzazione Simultanea della Connessione Figura 8. La principale ragione del three-way handshake e' di prevenire la confusione creata da vecchie inizializzazioni duplicate. Per occuparsi di questo, un speciale messaggio di controllo e' stato inventato. Se il TCP ricevente e' in uno stato non-sincronizzato (cioe', SYN-SENT, SYN-RECEIVED), ritorna in LISTEN al ricevimento di un reset accettabile. Se il TCP e' in uno stato sincronizzato (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), sospende la connessione e informa l'utente. Discuteremo questo secondo caso nelle connessioni "half-open". [Page 32] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> ... 3. (duplicato) ... --> SYN-RECEIVED 4. SYN-SENT <-- <-- SYN-RECEIVED 5. SYN-SENT --> --> LISTEN 6. ... --> SYN-RECEIVED 7. SYN-SENT <-- <-- SYN-RECEIVED 8. ESTABLISHED --> --> ESTABLISHED Recupero da un Vecchio SYN Duplicato. Figura 9. Come semplice esempio di recupero da duplicati vecchi, considera la figura 9. Alla linea 3, un vecchio SYN duplicato arriva al TCP B. Il TCP B non puo' dire che e' un duplicato vecchio, cosi' esso risponde normalmente (linea 4). Il TCP A rileva che il campo ACK non e' corretto e restituisce un RST (reset) con suo campo SEQ selezionato per rendere il segmento credibile. Il TCP B, al ricevimento del RST, ritorna allo stato LISTEN. Quando il SYN originale (gioco di parole voluto) arriva infine alla linea 6, la sincronizzazione procede normalmente. Se il SYN alla linea 6 e' arrivato prima del RST, uno scambio piu' complesso puo' essere avvenuto con degli RST spediti in entrambe le direzioni. Connessioni Half-Open e Altre Anomalie Una connessione stabilita e' detta "half-open" se uno dei due TCP ha chiuso o sospeso la connessione dalla sua parte senza che l'altro ne sapesse qualcosa, o se le due parti della connessione diventano de-sincronizzate a causa di un crash avvenuto con perdita di memoria. Connessioni del genere sarano automaticamente resettate se un tentativo di spedire dati da una parte e' effettuato. Tuttavia, le connessioni half-open sono inusuali, e la procedura di recupero e' leggermente complicata. Se dal lato A la connessione non esiste piu', allora un tentativo [Page 33] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento dall'utente del lato B di spedire qualsiasi dato su essa risultera' che il TCP del lato B ricevera' un messaggio di controllo dei reset. Tale messaggio indica al TCP del lato B che qualcosa e' sbagliato, ed e' prevista la sospensione della connessione. Supponi che due processi utenti A e B stiano comunicando con un altro quando si verifica un crash con la perdita di memoria da parte del TCP A. Dipendente dal supporto sul sistema operativo del TCP di A, e' probabile che qualche meccanismo di recupero esista. Quando il TCP e' di nuovo up, e' probabile che A parti ancora dall'inizio o da un punto di recupero. Di conseguenza, A probabilmente riprovera' ad APRIRE la connessione ancora o provera' a SPEDIRE sulla connessione che lui crede aperta. Nel secondo caso, esso riceve il messaggio di errore "connessione non aperta" dal TCP locale (di A). In un tentativo di stabilire la connessione, il TCP di A spedira' un segmento contenente il SYN, questo scenario guida all'esempio mostrato in figura 10. Dopo il crash del TCP di A, l'utente prova a ri-aprire la connessione. Il TCP B, nel frattempo, pensa che la connessione sia aperta. TCP A TCP B 1. (CRASH) (spedito 300,ricevuto 100) 2. CLOSED ESTABLISHED 3. SYN-SENT --> --> (??) 4. (!!) <-- <-- ESTABLISHED 5. SYN-SENT --> --> (Sospesa!!) 6. SYN-SENT CLOSED 7. SYN-SENT --> --> Scoperta di una Connessione Half-Open Figura 10. Quando il SYN arriva alla linea 3, il TCB, essendo in uno stato sincronizzato, e il segmento in arrivo fuori dalla window, risponde con un acknowledgemnt indicando quale sequenza si aspetta di vedere prossimamente (ACK 100). Il TCP A vede che questo segmento non riconosce niente di cio' che spedisce e, essendo non-sincronizzato, spedisce un reset (RST) perche' ha rilevato una connessione half-open. Il TCP B interrompe alla linea 5. Il TCP A continuera' a tentare [Page 34] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento di stabilire una connessione; il problema e' ora ridotto al 3-way handshake di base della rigura 7. Un altro interessante caso alternativo accade quando il TCP A crasha e il TCP B prova a spedire dati su quella che pensa che sia una connessione sincronizzata. Questo e' illustrato in figura 11. In questo caso, i dati arrivati al TCP A da TCP B (linea 2) sono inaccettabili perche' nessuna connessione simile esiste, cos' il TCP A spedisce un RST. L'RST e' cosi' il TCP B lo processa e interrompe la connessione. TCP A TCP B 1. (CRASH) (spedito 300,ricevuto 100) 2. (??) <-- <-- ESTABLISHED 3. --> --> (SOSPESA!!) Il Lato Attivo causa la Scoperta della Half-Open Figura 11. Nella figura 12, troviamo i due TCP, A e B con connessione passiva in attesa di SYN. Un vecchio duplicato arriva al TCP B (linea 2) mette B in azione. Un SYN-ACK e' restituito (linea 3) e impone al TCP A di generare un RST (l'ACK nella linea 3 non e' accettabile). Il TCP B accetta il reset e ritorna al suo stato LISTEN passivo TCP A TCP B 1. LISTEN LISTEN 2. ... --> SYN-RECEIVED 3. (??) <-- <-- SYN-RECEIVED 4. --> --> (ritorna a LISTEN!) 5. LISTEN LISTEN Vecchi SYN Duplicati Provocano un Reset su due Socket Passivi Figura 12. [Page 35] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Una varieta' di altri casi e' possibile, tutti i quali sono rappresentati seguendo le regole per la generazione e processione di RST. Generazione di Reset Come regola generale, il reset (RST) deve essere spedito ogni qualvolta un segmento che arriva non e' apparentemente interessato alla connessione corrente. Un reset non deve essere spedito se non e' chiato che questo e' il caso. Ci sono tre gruppi di stati: 1. Se la connessione non esiste (CLOSED) allora un reset e' spedito in risposta a ogni segmento in arrivo ad eccezzione di un altro reset. In particolare, i SYN indirizzati a una connessione non-esistente sono rifiutati attraverso questo mezzo. Se il segmento in arrivo ha un campo ACK, il reset prende il suo sequence number dal campo ACK del segmento, altrimenti il reset ha sequence number zero e il campo ACK e' settato per la somma del sequence number e la lunghezza del segmento del segmento in arrivo. La connessione rimane nello stato CLOSED. 2. Se la connessione e' in qualsiasi stato non-sincronizzato (LISTEN, SYN-SENT, SYN-RECEIVED), e il segmento in arrivo riconosce qualcosa non ancora spedito (il segmento trasporta un ACK non accettabile), o se il segmento in arrivo ha il livello di sicurezza o compartimento che non corrisponde esattamente a il livello e compartimento richiesto per la connessione, un reset e' spedito. Se il nostro SYN non e' stato riconosciuto e il livello di precedenza del segmento in arrivo e' superiore del livello di precedenza richiesto allora uno aumenta il livello di precedenza locale (se permesso dall'utente e dal sistema) oppure spedisce un reset; oppure se il livello di precedenza del segmento in arrivo e' minore del livello di precedenza richiesto allora continua se la precedenza corrisponde esattamente (se il TCP remoto non puo' aumentare il livello di precedenza per fare corrispondere i nostri questo sara rilevato nel prossimo segmento che spedisce, e la connessione sara' poi' terminata). Se il nostro SYN e' stato riconosciuto (forse in questo segmento in arrivo) il livello di precedenza del segmento in arrivo deve corrispondere esattamente con il livello di precedenza locale, se no, un reset deve essere spedito. Se il segmento in arrivo ha un campo ACK, il reset prende il suo sequence number dal campo ACK del segmento, altrimento il reset ha il sequence number a zero e il campo ACK e' settato per la somma del sequence number e la lunghezza del segmento del segmento in arrivo. La connessione rimane nello stesso stato. [Page 36] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento 3. Se la connessione e' in uno stato sincronizzato (STABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), ogni segmento non accettabile (fuori dal sequence number della window oppure un numero di riconoscimento non accettabile) deve ottenere solo un segmento di riconoscimento vuoto contenente il curret-sequence number e un riconoscimento idicante il porssimo sequence number previsto di essere ricevuto, e la connessione rimane allo stesso stato Se il segmento in arrivo ha un livello di sicurezza, o compartimento, o precedenza che non corrisponde esattamente con il livello, compartimento, e precedenza richiesta della connessione, un reset e' spedito e la connessione va allo stato CLOSED. Il reset prende il suo sequence number dal campo ACK del segmento in arrivo. Elaborazione di Reset In tutti i stati eccetto SYN-SENT, tutti i segmenti reset (RST) sono validati attraverso il controllo dei loro SEQ-fiels. Un reset e' valido se il suo sequence number e' entro la window. Nello stato SYN-SENT (un RST ricevuto in risposta a un SYN iniziale), l'RST e' accettabile se il campo ACK riconosce il SYN. Il ricevente del SYN prima lo convalida, poi cambia lo stato. Se il ricevente era nello stato LISTEN, lo ignora. Se il ricevente era nello stato SYN-RECEIVED ed e' stato precedentemente nello stato LISTEN, allora il ricevente ritorna allo stato LISTEN, altrimenti il ricevente sospende la connessione e va allora stato CLOSED. Se il ricevente era in qualsiasi altro stato, esso sospende la connessione, avvisa l'utente e va allo stato CLOSED. 3.5. Chiusura di una connessione La CLOSE e' una operazione che significa "Io non ho altri dati da spedire." L'idea di chiudere una connessione full-duplex e' un cosa con interpretazioni ambigue, naturalmente, poiche' non puo' essere evidente come trattare il lato ricevente della connessione. Abbiamo scelto di trattare la CLOSE in un unico modo. L'utente che CHIUDE puo' continuare a RICEVERE finche' non dice all'altro lato che anche lui ha CHIUSO. In questo modo, un programma puo' dare inizio a parecchie SEND seguite da una CLOSE, e poi continuare a ricevere finche' non viene segnalato che una RECEIVE fallisce perche' l'altro lato ha CHIUSO. Supponiamo che il TCP segnalera' un utente, anche se le RECEIVE non sono sicure che abbia chiuso, cosi' l'utente puo' terminare il suo lato in modo elegante. Un TCP trasportera' in modo affidabile tutti i buffer SENT prima che la connessione sia CHIUSA cosi' un utente che non prevede di avere ancora dati in ricezione necessita solo di aspettare di vedere che la connessione e' stata CHIUSA con successo per sapere che tutti i suoi dati erano ricevuti dal TCP di destinazione. Gli utenti devono continuare a tenere sotto controllo le connessioni che chiudono per spedire finche' il TCP dice che non vuole altri dati. [Page 37] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Fondamentalmente ci sono tre casi: 1) L'utente inizia dicendo al TCP di CHIUDERE la connessione 2) Il TCP remoto inizia spedendo un segnale di controllo FIN 3) Entrambi gli utenti CHIUDONO simultaneamente Caso 1: L'utente locale inizia la chiusura In questo caso, un segmento FIN puo' essere costruito e messo nella coda dei segmenti in uscita. Ulteriori SEND dall'utente non saranno accettate dal TCP, ed entra nello stato FIN-WAIT-1. Le RECEIVE sono ammesse in questo caso. Tutti i segmenti precedenti e includenti il FIN saranno ritrasmessi finche' non saranno riconosciuti. Quando l'altro TCP ha sia accettato il FIN e spedito un proprio FIN, il primo TCP puo' fare l'ACK di questo FIN. Nota che un TCP che riceve un FIN fara' l'ACK, ma non spedira' un suo proprio FIN finche' l'altro utente ha CHIUSO la connessione a sua volta. Caso 2: Il TCP riceve un FIN dalla rete Se un FIN non richiesto arriva dalla rete, il TCP ricevente puo' fare l'ACK su questo e dire all'utente che la connessione sta chiudendo. L'utente rispondera' con una CLOSE, su il quale il TCP puo' trasmettere un FIN all'altro TCP dopo avere spedito i dati rimanenti. Il TCP allora attende finche' il proprio FIN non sia stato riconosciuto, dopodiche' cancella la connessione. Se un ACK non e' il prossimo, dopo il timeout dell'utente la connessione e' sospesa e l'utente e' avvertito. Caso 3: entrambi gli utenti chiudono simultaneamente Una CLOSE simultanea dagli utenti da entrambe le estremita' di una connessione causa lo scambio di segmenti FIN. Quando tutti i segment precedenti i FIN sono stati processati e riconosciuti, ogni TCP puo' fare l'ACK del FIN che ha ricevuto. Entrambi, dopo avere ricevuti quei ACK, cancelleranno la connessione. [Page 38] September 1981 Protocollo di Controllo della Tramissione Specifiche di Funzionamento TCP A TCP B 1. ESTABLISHED ESTABLISHED 2. (Chiudere) FIN-WAIT-1 --> --> CLOSE-WAIT 3. FIN-WAIT-2 <-- <-- CLOSE-WAIT 4. (Chiudere) TIME-WAIT <-- <-- LAST-ACK 5. TIME-WAIT --> --> CLOSED 6. (2 MSL) CLOSED Normale Sequenza di Chiusura Figura 13. TCP A TCP B 1. ESTABLISHED ESTABLISHED 2. (Chiudere) (Chiudere) FIN-WAIT-1 --> ... FIN-WAIT-1 <-- <-- ... --> 3. CLOSING --> ... CLOSING <-- <-- ... --> 4. TIME-WAIT TIME-WAIT (2 MSL) (2 MSL) CLOSED CLOSED Sequenza Simultanea di Chiusura Figura 14. [Page 39] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento 3.6. Precedenza e Sicurezza L'idea e' che una connessione e' ammessa solo tra porte operanti con esattamente gli stessi valori di sicurezza/compartimento e il livello maggiore del livello di sicurezza richiesto dalle due porte. I parametri di precedenza e sicurezza usati nel TCP sono essattamente quelli definiti nell'Internet Protocol (IP) [2]. Attraverso questa caratteristica del TCP il termine "sicurezza/compartimento" e' inteso a indicare i parametri di sicurezza usati nell'IP includenti sicurezza, compartimento, gruppi utenti, e restrinzioni di gestione. Una connessione che fa dei tentativi con valori di sicurezza/compartimento non corrispondenti o livelli inferiori di precedenza devono essere rifiutati spedendo un reset. Il rifiuto di una connessione dovuto a una precedenza troppo bassa avviene solo dopo che il riconoscimento del SYN e' stato ricevuto. Nota che i moduli TCP che operano solo al valore prestabilito di precedenza avranno ancora da controllare la precedenza del segmento in arrivo e possibilimente aumentano il livello di precedenza che loro usano nella connessione. I parametri di sicurezza possono essere usati anche in un ambiente non-sicuro (i valori indicherebbero dati non-classificati), in questo modo gli host in contesti non-sicuri devono prepararsi a riceve i parametri di sicurezza, anche se non necessitano di spedirli. 3.7. Trasmissione di Dati Una volta che la connessione e' stabilita i dati sono trasmessi attraverso lo scambio di segmenti. Poiche' questi segmenti possono essere persi a causi di errori (fallimento della verifica del checksum), o congestioni della rete, il TCP usa la ritrasmissione (dopo un timeout) per assicurare la consegna di ogni segmento. Segmenti doppi possono arrivare a causa di ritrasmissioni della rete o del TCP. Come discusso nella sezione sui sequence number il TCP effettua verifiche sicure sui sequence number e acknowledgment nei segmenti per verificare la loro ammissibilita'. Il mittente dei dati tiene traccia del prossimo sequence number da usare nella variabile SND.NXT. Il ricevente dei dati tiene traccia del prossimo sequence number da attendere nella variabile RCV.NXT. Il mittente dei dati tiene traccio dei vecchi sequence number non riconosciuti nella variabile SND.UNA. Se il flusso di dati e' momentaneamente sospeso e tutti i dati spediti sono stati riconosciuti allora le tre variabili saranno uguali. Quando il mettente crea un segmento e lo trasmette il mittente aumenta la SND.NXT. Quando il ricevente accetta un segmento esso aumenta la RCV.NXT e spedisce un acknowledgment. Quando il mittente dei dati riceve [Page 40] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento un acknowledgment esso aumenta la SND.UNA. Il limite da cui i valori di queste variabili differiscono e' una misura del ritardo nella comunicazione. La quantita' di cui le variabili sono aumentate e' la lunghezza dei dati nel segmento. Nota che una volta nello stato ESTABLISHED tutti i segmenti devono trasportare l'informazione del riconoscimento corrente. La chiamata utente CLOSE richiama la funzione push, come fatto dal flag di controllo FIN in un segmento in arrivo. Timeout di Ritrasmissione A causa della variabilita' delle reti che compongono un sistema interconnesso e l'ampia gamma di usi delle connessioni TCP, il timeout di ritrasmissione deve essere determinato dinamicamente. Una procedura per determinare un tempo di ritrasmissione e' qui dato a titolo illustrativo. Un Esempio della Procedura di Timeout della Ritrasmissione Misurare il tempo trascorso tra la spedizione di un otteto di dati con un sequence number particolare e il ricevimento di un acknowledgment che copre quel sequence number (i segmenti spediti non devono corrispondere ai segmenti ricevuti). Questo tempo trascorso misurato e' il Round Trip Time (RTT). il prossimo calcola un Smoothed Round Trip Time (SRTT): SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) e basato su questo, calcola il timeout di ritrasmissione (RTO): RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]] dove UBOUND e' il limite maggiore del timeout (ad esempio, 1 minuto), LBOUND e' il limite minore del timeout (ad esempio, 1 secondo), ALPHA e' il fattore di regolazione (ad esempio, .8 a .9), e BETA e' il fattore della variante di ritardo (ad esempio, 1.3 a 2.0). La Comunicazione di Informazioni Urgenti L'obbiettivo del meccanismo di urgenza del TCP e' di permettere all'utente mittente di stimolare l'utente ricevente af accettare alcuni dati urgenti e per permettere al TCP ricevente di indicare all'utente ricevente quando gli attuali dati urgente conosciuti sono stati ricevuti dall'utente. Questo meccanismo permette a un punto nel flusso di dati di essere dichiarato come fine delle informazioni urgenti. Ogni qualvolta questo punto e' in anticipo rispetto al sequence number di ricezione (RCV.NXT) del TCP ricevente, questo TCP deve dire all'utente di andare nella "modalita' urgente"; quando il sequence number ricevuto intercetta l'urgent pointer, il TCP deve dire all'utente di andare nella "modalita' normale". [Page 41] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Se l'urgnt pointer e' aggiornato mentre l'utente e' in "modalita' urgente", l'aggiornamento sara' invisibile all'utente. Il metodo impiega un campo urgente il quale e' trasportato in tutti i segmenti trasmessi. Il flag di controllo URG indica che il campo urgente e' importante e deve essere aggiunto al sequence number del segmento per creare l'urgent pointer. Il senso di questo flag indica che non ci sono dati in sospeso. Per spedire una indicazione urgente l'utente deve anche spedire almeno un otteto di dati. Se l'utente mittente indica anche una push, la distribuzione attuale delle informazioni urgenti al processo della destinazione č aumentata. Gestione delle Window La window e' spedita in ogni segmento indica una gamma di numeri di sequenza che la window (del ricevente dei dati) e' attualmente preparata ad accettare. C'e' un'ipotesi secondo la quale cio' e' associato allo spazio attualmente disponibile nel buffer di dati per questa connessione. Indicando una window ampia si incoraggiano le trasmissioni. Se altri dati che possono essere accettati arrivano, saranno scartati. Cio' risultera' in una ritrasmissione eccessiva, aggiungendosi inutilmente al carico della rete e dei TCP. Indicando una window stretta si puo' restringere la trasmissione dei dati al punto di introdurre un round trip delay tra ogni nuovo segmento trasmesso. I meccanismi forniti permettono ad un TCP di fare emettere una grande window e di fare emettere successivamente window piu' piccole senza accettare altri dati. Questo metodo, chiamato "restringere la finestra," e' fortemente sconsigliato. Il principio fondamentale dice che i TCP non restringeranno le window da soli, ma sanno preparati per un tale comportamente da parte degli altri TCP. Il TCP mittente deve essere preparato ad accettare dall'utente e spedire almeno un otteto di nuovi dati anche se la window spedita e' zero. Il TCP mittente deve ritrasmettere regolarmente al TCP ricevente anche quando la window e' zero. Due minuti sono raccomandati per l'intervallo di ritrasmissione quando la window e' zero. Questa ritrasmissione e' essenziale per garantire che quando un TCP ha un window a zero il ri-apritore della window dovra essere riportartato in modo affidabile all'altro. Quando il TCP ricevente ha una window a zero e un segmento arriva, esso deve tranquillamente spedire un riconoscimento mostrando il suo prossimo numero di sequenza previsto e la window corrente (zero). Il TCP mittente impacchetta i dati per essere trasmessi in segmenti [Page 42] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento i quali entreranno nella window corrente, e puo' reimpacchettare i segmenti nella coda di ritrasmissione. Il reimpacchettamento non e' richiesto, ma puo' essere utile. In una connessione con un-senso di flusso dei dati, l'informazione della window sara' trasportata nei segmenti di riconoscimento che hanno tutti gli stessi sequence number cosi' non ci sara' modo di riordinarli se non arrivano in ordine. Questo non e' un serio problema, ma permettera' all'informazione della window di essere in occasioni temporamente basata su vecchi rapporti dal riceventi dei dati. Un miglioramento al fine di evitare questo problema e' di agire sull'informazione della window dai segmenti che trasportano il acknowledgmnet piu' alto (cioe' segmenti con un acknowledgment number uguale o maggiore del piu' alto ricevuto precedentemente). La procedura di gestione della window ha un'influenza significante sul rendimento della connessione. I commenti seguenti sono suggerimenti agli implementatori. Suggerimenti per la Gestione della Window Allocare una window troppo piccola causa la trasmissione dei dati in molti segmenti piccoli quando invece le prestazioni migliori si ottengono usando meno segmenti. Un suggerimento per evitare le window piccole e' per il ricevente di evitare di aggiornare una window finche' le allocazioni aggiuntive non sono almeno a X percento delle allocazioni massime possibili per la connessione (dove X puo' essere da 20 a 40). Un'altro suggerimento per il mittente per evitare di spedire piccoli segmenti attentendo finche' la window e' larga abbbastanza prima di spedire dati. Se l'utente segnala una funzione push allora i dati devono essere spediti anche se esso e' un piccolo segmento. Nota che gli acknowledgment non dovrebbero essere in ritardo oppure si verifichera' una ritrasmissione non necessaria. Una strategia sarebbe di spedire un acknowledgment quando un piccolo segmento arriva (senza aggiornare l'informazione della window), e di spedire allora un altro acknowledgment con una nuova informazione della window quando la window e' piu' larga. Il segmento spedito per trovare un window a zero puo' anche iniziare una divisione dei dati trasmessi in segmenti via via piu' piccoli. Se un segmento contenente un singolo otteto di dati spedito per trovare una window a zero e' accettato, esso impiega un otteto della window ora disponibile. Se il TCP mittente spedisce semplicemente come puo' ogni volta che la window non e' zero, i dati trasmessi saranno frammentati alternativamente in grandi e piccoli segmenti. Come il tempo continua, pause occasionali nel ricevente che fanno l'allocazione delle window disponibile [Page 43] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento provochera' la frammentazione dei segmenti grandi in piccoli e non abbastanza grandi. E dopo un po' gran parte della trasmissione dei dati sara' costituita in gran parte da piccoli segmenti. Il suggerimento qui e' che gli implementatori del TCP devono attivamente tentare di unire le piccole allocazione delle window in window piu' larghe, poiche' i meccanismi per gestire le window tendono a condurre a window molto piccole nel modo piu' semplice delle implementazioni libere. 3.8. Interfacce Ci sono naturalmente due punti di vista delle interfacce: l'interfaccia utente/TCP e l'interfaccia TCP/livello-inferiore. Noi abbiamo un modello ragionevolmente elaborato dell'interfaccia utente/TCP, ma l'interfaccia con il modulo di protocollo di levello inferiore e' lasciata imprecisata qui, poiche' sara' specificata nel dettaglio attraverso le precisazioni del livello di protocollo inferiore. Nel caso in cui il livello inferiore e' l'IP notiamo alcuni dei valori dei parametri che il TCP puo' usare. Interfaccia utente/TCP La seguente descrizione funzionale dei comandi utente che il TCP e', nel migliore dei casi, fittizia, poiche' ogni sistema operativo avra' approcci differenti. Di conseguenza, dobbiamo avvertire i lettori che differenti implementazioni del TCP possono avere differenti interfacce utente. Tuttavia, tutti i TCP devono fornire un certo insieme minimo di servizi per garantire che tutte le implementazioni del TCP possano supportare la stessa gerarchia di protocolli. Questa sezione specifica le interfacce di funzionamento richieste da tutte le implementazioni del TCP. Comandi Utente del TCP Le sezioni seguenti caratterizzano dal punto di vista funzionale un interfaccia UTENTE/TCP. La notazione usata e' simile a gran parte delle procedure o chiamate di funzioni nei linguaggi di alto livello, ma questo uso non significa l'eliminazione delle trap service calls (ad esempio, le SVC, le UUO, le EMT). I comandi utente descritti sotto specificano le funzioni di base che il TCP deve effettuare per supportare connessione tra interprocessi. Implementazioni individuali devono definire un loro proprio formato esatto, e possono fornire combinazioni o sottoinsiemi delle funzioni di base in singole chiamate. In particolare, alcune implementazioni possono desiderare di APRIRE automaticamente una connessione alla prima SEND o RECEIVE richiesta dall'utente per una data connessione [Page 44] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Nei mezzi per la comunicazione tra interprocessi, il TCP non deve solo accettare i comandi, ma anche restituire l'informazione al processo che lo serve. Il secondo caso consiste in: (a) informazioni generali riguardanti una connessione (ad esempio, gli interrupt, chiusure remote, legarsi di socket remoti non specificati). (b) rispondere al comendo utente specifico indicando il successo o i vari tipi di fallimento. Open Formato: OPEN (porta locale, socket remoto, attiva/passiva [, timeout] [, precedenza] [, sicurezza/compartimento] [, opzioni]) -> nome della connessione locale Supponiamo che il TCP locale sia consapevole dell'identita' del processo che egli server e controllera' l'autorita' del processo per usare la connessione specificata. Dipendendo dalle implementazioni del TCP, la rete locale e il contrassegno del TCP per l'indirizzo sorgente sarano forniti o dal TCP oppure da un protocollo inferiore (ad esempio, l'IP). Queste considerazioni sono il risultato della preocupazione riguardo alla sicurezza, anche se non c'e' alcun TCP capace spacciarsi per un altro, e cosi' via. Analogamente, nessun processo puo' spacciarsi per un'altro senza la collusione del TCP. Se il flag attiva/passiva e' impostato a passiva, allora c'e' una chiamata per una LISTEN per una connessione in arriva. Una open passiva puo' o avere un socket remoto completamente specificato per attendere una particolare connessione oppure un socket remoto non specificato che attente per qualsiasi chiamata. Una chiamata completamente specificata puo' essere attivata da una sottosequenza di esecuzione di una SEND. Un transmission control block (TCB) e' creato e parzialmente riempito con dei dati dai parametri dei comandi della OPEN. In un comando di una OPEN attiva, il TCP inziera' la procedura per sincronizzare (cioe', stabilire) la connessione immediatamente. Il timeout, se presente, permette al chiamante di imposta un timeout per tutti i dati proposti al TCP. Se i dati non sono consegnati con successo alla destinazione entro il periodo di timeout, il TCP interrompera' la connessione. Il valore globale di default e' cinque minuti. Il TCP o qualche componente del sistema operativo verifichera' l'autorita' degli utenti per aprire una connessione con la [Page 45] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento precedenza oppure sicurezza/compartimento specificati. L'assenza della precedenza oppure delle specificazioni di sicurezza/compartimento nella chiamata OPEN indicano che i valori prestabiliti devono essere usati. Il TCP accettera' richieste in arrivo corrispodenti soltanto se le informazioni di sicurezza/compartimento sono esattamente le stesse e solo se la precedenza e' uguale o superiore della precedenza richiesta nella chiamata OPEN. La precedenza per una connessione e' il piu' alto dei valori richiesto in una chiamata OPEN e ricevuto dalla richiesta in arrivo, e fissato a tale valore per la durata della connesione. Gli esecutori vorranno dare il controllo dell'utente a questa negoziazione precedente. Per esempio, l'utente puo' permettere di specificare che la precedenza debba essere esattamente corrispodente, oppure che ogni tentativo di aumentare la precedenza debba essere confermato dall'utente. Un nome della connessione locale sara' restituito all'utente dal TCP. Il nome della connessione locale puo' allora essere usato come abbreviazione per la connessione definita dall'accopiamento . Send Formato: SEND (nome connessione locale, indirizzo del buffer, conteggio dei byte, flag PUSH, flag URGENT [, timeout]) Questa chiamata causa l'invio dei dati contenuti nel buffer dell'utente indicato alla connessione indicata. Se la connessione non e' stata aperta, la SEND lo considera un errore. Alcune implementazioni possono permettere ad utenti di SPEDIRE prima; in questo caso, una OPEN automatica sara' effettuata. Se il processo chiamante non e' autorizzato ad usare questa connessione, e' restituito un errore. Se il flag PUSH e' impostato, i dati devono essere trasmessi subito al ricevente, e il bit PUSH sara' impostato nell'ultimo segmento TCP creato dal buffer. Se il flag PUSH non e' impostato, i dati possono essere mescolati con i dati delle sottosequenze SEND per efficienza di trasmissione. Se il flag URGENT e' impostato, i segmenti spediti al TCP di destinazione avrano un puntatore di urgenza impostato. Il TCP ricevente segnalera' la condizione di urgenza al processo ricevente se il puntatore di urgenza indica che i dati precedenti al puntatore di urgenza non sono stati impiegati dai processi riceventi. Lo scopo dell'urgenza e' di stimolare il ricevente ad elaborare i dati urgenti e di indicare al ricevenze quando tutti [Page 46] September 1981 Protocollo di Controllo della Connessione Specifiche di Funzionamento i dati urgenti sono stati ricevuti. Il numero di volte che il TCP dell'utente mittente segnala l'urgenza non sara' per forza uguale al numero di volte che l'utente ricevente notifichera' la presenza di dati urgenti. Se nessun socket remoto era specificato nella OPEN, ma la connessione e' stabilita (ad esempio, perche' una connessione on LISTENing dovuto a un segmento remoto in arrivo per il socket locale), allora il buffer creato e' spedito al socket remoto implicato. Gli utenti che fanno uso di OPEN con un socket remoto non specificato possono fare uso di SEND senza conoescere l'indirizzo del socket remoto. Tuttavia, se una SEND e' tentata prima che il socket remoto diventi specificato, sara' riportato un errore. Gli utenti possono usare la chiamata STATUS per determinare lo STATO della connessione. In alcune implementazioni il TCP puo' notificare l'utente quando un socket non specificato e' limitato. Se un timeout e' specificato, il timeout dell'user corrente per questa connessione e' cambiato a uno nuovo. In implementazioni piu' semplici, la SEND non restituira' il controllo al processo mittente finche' o la tramissione sara' completa oppure finche' il timeout sia stato oltrepassato. Tuttavia, questo semplice metodo e' soggetto ai deadlock (per esempio, entrambi i lati della connessione provano a fare SEND prima di fare qualsiasi RECEIVE) e offre prestazioni povere, cosi' esso non e' raccomandato. Una implementazione piu' sofisticata ritornera' immediatamente per permettere ai processi di eseguirsi in modo concorrente con l'I/O della rete, e, inoltre, per permettere a SEND multiple di progredire. Le SEND multiple sono servite in ordine di arrivo, cosi' il TCP accodera' quelli che non puo' assistere immediatamente. Abbiamo supposto implicitamente che una interfaccia utente asincrona nella quale un SEND trae alcuni tipi di SIGNAL o pseudo-interrupt dal TCP servente. Una alternativa e' di riportare una risposta immediatamente. Per esempio, le SEND possono restituire immediatanemente un acknowledgment locale, anche se il segmento spedito non e' stato riconosciuto dal TCP remoto. Possiamo ottimisticamente supporre un eventuale successo. Se sbagliamo, la connessione sara' chiusa ad ogni modo a causa del timeout. In implementazioni di questo tipo (sincrone), ci sono ancora alcuni segnali asincroni, ma questi si occuperanno della connessione da soli, e senza segmenti o buffer specifici. Affinche' il processo distingua le indicazioni di errori o successo per SEND differenti, puo' essere appropriato per l'indirizzo dei [Page 47] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento buffer che siano riportati con il codice di risposta alla richiesta SEND. I segnali TCP-a-utente sono discussi sotto indicando l'informazioni che dovrebbero essere restituite al processo chiamante. Receive Formato: RECEIVE (nome della connessione locale. indirizzo del buffer, conteggio dei byte) -> conteggio dei byte, flag urgent, flag push Questo comando alloca un buffer ricevente con una connessione specificata. Se una OPEN non precede questo comando oppure il processo chiamante non e' autorizzato ad usare questa connessione, e' restituito un errore. Nell'implementazione piu' semplice, il controllo non ritornera' al programma chiamante finche' o il buffer e' pieno, oppure si verifica qualche errore, ma questo schema e' altamente soggetto ai deadlock. Una implementazione piu' sofisticata consentirebbe a parecchie RECEIVE di essere immediatamente sospeso. Questi sarebbero riempiti come segmenti in arrivo. Questa strategia consente un rendimento piu' elvato al costo di uno schema piu' elaborato (possibilmente asincrono) per notificare ad il programma chiamante che una PUSH e' stata vista o un buffer e' riempito. Se arrivano abbastanza dati per riempire il buffer prima che una PUSH sia vista, il flag PUSH non sara' impostato in risposta alla RECEIVE. Il buffer sara' riempito fino a che puo' tenere i dati. Se una PUSH e' vista prima che il buffer sia riempito, il buffer sara' rinviato parzialmente e una PUSH segnalata. Se ci sono dati urgenti l'utente sara' informato appena essi arrivano attraverso un segnale di TCP-a-utente. L'utente ricevente dovrebbe in questo modo essere nella "modalita' urgente". Se il flag URGENT e' settato, i dati urgenti suplementari rimangono. Se il flag URGENT non e' settato, questa chiamata a RECEIVE ha restituito tutti i dati urgenti, e l'utente ora puo' lasciare la "modalita' urgente". Nota che i dati seguenti al puntatore di urgenza (dati non-urgenti) non possono essere spediti all'utente nello stesso buffer essere preceduti da dati urgenti, a meno che la linea del campo non sia marcata "pulita" per l'utente. Per distinguere tra le parecchie RECEIVE eccezzionali e per prendere cure del caso in cui un buffer non e' completamente riempito, il codice di ritornoe ' accompagnato sia da un puntatore di buffer sia da un conteggio di byte indicando l'attuale lunghezza dei dati ricevuti. Implementazioni alternative di RECEIVE potrebbero fare assegnare [Page 48] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento al TCP la registrazione di memoria temporanea, oppure il TCP potrebbe condividere un anello di buffer con l'utente. Close Formato: CLOSE (nome della connessione locale) Questo comando causa la chiusura della connessione specificata. Se la connessione non e' aperta o il processo chiamante non e' autorizzato ad usare questa connessione, e' restituito un errore. L'operazione di chiusura e' intesa di effere una operazione aggraziata nel senso che le SEND eccezzionali saranno trasmesse (e ritrasmessi), per quanto il controllo di flusso lo permetta, finche' tutti siano stati serviti. In questo modo, dovrebbe essere accettabile di creare parecchie chiamate SEND, seguite da una CLOSE, e aspettarsi che tutti i dati siano spediti alla destinazione. Dovrebbe anche essere chiato che gli utenti dovrebbero continuare a RICEVERE su una connessione CHIUSA, poiche' l'altro lato puo' provare a trasmettere i suoi ultimi dati. In questo modo, la CLOSE significa "Io non ho altro da spedire" ma non significa "non spediro' niente altro". Puo' succedere (se il protocollo del livello utente non e' ben pensato) che il lato in chiusura sia incapace di sbarazzarsi di tutti i suoi dati prima del timeout. In tal caso, la CLOSE tramuta in ABORT, e il TCP in chiusura lascia perdere. Un utente puo' CHIUDERE la connessione in qualunque momento di sua propria iniziativa, o in risposta a vari inviti dal TCP (ad esempio, chiusura remota eseguita, timeout di trasmissione trascorso, destinazione inaccessibile). Poiche' chiudere una connessione richiede la comunicazione con il TCP remoto, le connessioni possono rimanere nello stato in chiusura per un breve tempo. Tentativi di riaprire un connessione prima che il TCP risponde al comando CLOSE, avranno errori in riposta. La close include anche una funzione push. Status Formato: STATUS (nome della connessione locale) -> dati della condizione Questa e' un implementazione dipendente dal comando dell'utente e potrebbe essere esclusa senza effetti contrari. L'informazione restituita dovrebbe tipicamente provenire dal TCB associato con la connessione. Questo comando restituisce un blocco di dati contente le seguenti informazioni: socket locale, [Page 49] September 1981 Protocollo di Controllo della Tramissione Specifiche di Funzionamento socket remoto, nome della connessione locale, window ricevuta, window trasmessa, stato della connessione, numero di buffer in attesa di acknowledgment, numero di buffer in corso di ricezione, stato di urgenza, precedenza, sicurezza/comparimento, e il timeout di trasmissione. Conforme allo stato della connessione, o della stessa implementazione, alcune di queste informazioni possono non essere disponibili o importanti. Se il processo chiamante non e' autorizzato ad usare questa connessione, e' restituito un errore. Questo evita che processi non autorizzati ottengano informazioni riguardo ad una connessione. Abort Formato: ABORT (nome della connessione locale) Questo comando causa la sospensione di tutte le SEND e RECEIVE in corso, la rimozione del TCB, e l'invio di un speciale messaggio di RESET dal TCP dell'altro lato della connessione. Conforme al tipo di implementazione, gli utenti possono ricevere avvisi di sospensione per ogni SEND o RECEIVE speciale, oppure ricevere semplicemente un acknowledgmnet-di-ABORT. Messaggi del TCP-a-Utente E' supposto che l'ambiente di un sistema operativo fornisca un mezzo al TCP per avvertire in modo asincrono il programma utente. Quando il TCP avvisa un programma utente, certe informazioni sono passate all'utente. Nello specifico le informazioni saranno spesso un messaggio di errore. In altri casi ci saranno informazioni relative al completamento di SEND oppure RECEIVE o altre chiamate utente. E' fornita la seguente informazione: Nome della Connessione locale Sempre Stringa di Risposta Sempre Indirizzo del Buffer Spedizione & Ricezione Conteggio dei Byte (conteggio byte ricevuti) Ricezione Flag Push Ricezione Flag Urgent Ricezione [Page 50] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento L'interfaccia TCP/Livello-Inferiore Il TCP chiama un modulo di protocollo di livello inferiore per spedire e ricevere realmente informazioni su una rete. Un caso e' quello del sistema di interconnessio della ARPA dove il livello inferiore e' il Protocollo Internet (IP) [2]. Se il protocollo di livello inferiore e' l'IP esso fornisce argomenti per un tipo di servizio e per un time to live. Il TCP usa le seguenti impostazioni per questi parametri: Tipo di Servizio = Precedenza: come al solito, Ritardo: normale, Rendimento: normale, Affidabilita': normale; oppure 0000000. Time to Live = un minuto, oppure 00111100. Nota che la durata supposta del segmento massimo e' due minuti. Qui chiederemo esplicitamente che un segmento sia eliminato se esso non puo' essere spedito attraverso il sistema internet entro un minuto. Se il livello inferiore e' l'IP (o un altro protocollo che fornisca questa caratteristica) e l'instradamento del mittente e' usato, l'interfaccia deve permettere che le informazioni di instradamento siano trasmesse. Questo e' specialmente importante, in modo che gli indirizzi del mittente de del destinatario usati nel checksum del TCP siano il mittente originale e l'ultima destinazione. E' anche importante preservare l'instradamento restituito al fine di rispondere a richieste di connessione. Qualsiasi protocollo di livello inferiore dovra' fornire l'indirizzo del mittente, l'indirizzo di destinazione, e i campi del protocollo, e qualche modo per determinare la "lunghezza del TCP", entrambi al fine di fornire il servizio equivalente dell'IP e per essere usato nel checksum del TCP. [Page 51] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento 3.9. Esaminazione di Eventi L'esame rappresentato in questa sezione e' un esempio di una possibile implementazione. Altre implementazioni possono avere sequenze di elaborazione un po' differenti, ma dovrebbero differire da quelli di questa sezione solo nel dettaglio, non in sostanza. L'attivita' del TCP puo' essere rappresentata come risposta a degli eventi. Gli eventi che si verificano possono essere ragruppati in tre categorie: chiamate utenti, segmenti in arrivo, e timeout. Questa sezione descrive l'elaborazione che il TCP fa in risposta ad ognuno di questi eventi. In molti casi l'elaborazione richiede dipendenze sullo stato della connessione. Eventi che si Verificano: Chiamate Utente OPEN SEND RECEIVE CLOSE ABORT STATUS Segmenti in Arrivo SEGMENT ARRIVES Timeout USER TIMEOUT RETRANSMISSION TIMEOUT TIME-WAIT TIMEOUT Il modello dell'interfaccia TCP/utente e' che i comandi utente ricevono un ritorno immediato e possibilmente una risposta ritardata attraverso un evento o un pseudo-interrupt. Nelle descrizioni seguenti, il termine "segnale" significa che causa un risposta ritardata. Risposte di errori sono dati come stringhe di caratteri. Per esempio, i comandi utente che si riferiscono a una connessione che non esiste ricevono "errore: connessione non aperta". Nota in quanto segue che tutta l'aritmetica sui sequence number, acknowledgment number, window, eccetera, l.a dimensione del sequence number space e' dato da 2**32 [Page 52] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Un modo naturale di pensare circa l'elaborazione di segmenti in arrivo e' di immaginare che sono prima verificati per i sequence number appropriato (cioe', che il loro contenuti non 'mentiscano' sulla gamma delle "window ricevute" previste nello sequence number space) e poi che siano di solito accodati ed elaborati in ordine dei numeri di sequenza. Quando un segmento sovrascrive un altro gia' ricevuto, ricostruiamo il segmento per contenere solo nuovi dati, e aggiustiamo i campi dell'header perche' siano consistenti. Nota che se nessun cambiamento di stato e' menzionato, il TCP rimane nello stesso stato. [Page 53] September 1981 Transmission Control Protocol Functional Specification Chiamata OPEN Chiamata OPEN STATO CLOSED (cioe', il TCB non esiste) Crea un nuovo blocco di controllo della trasmissione (TCB) per tenere le informazioni dello stato della connessione. Riempe l'identificatore locale del socket , socket remoti, precedenza, sicurezza/compartimento, e l'informazione del timeout dell'utente. Nota che alcune parti del socket remoto possono essere imprecise in una OPEN passiva e sono riempite dai parametri dei segmenti SYN in arrivo. Verificare la sicurezza e la precedenza richieste sono permesse a questo utente, se non restituisce "errore: precedenza non permessa" oppure "errore sicurezza/compartimento non permessi." Se una passiva entra nello stato LISTEN e ritorna. Se l'attiva e il socket remoto e' imprecisato, restituisce "errore: socket remoto imprecisato"; se attiva e il socket remoto e' specificato, manda un segmento SYN. Una iniziale spedizione di sequence number (ISS) e' selezionata. Un segmento SYN della forma e' spedito. Imposta SND.UNA a ISS, SND.NXT a ISS+1, entra nello stato SYN-SENT, e ritorna. Se il chiamante non ha accesso al socket locale specificato, restituisce "errore: connessione illecita per questo processo". Se non c'e' spazio per creare una nuova connessione, restituisce "errore: risorse insufficienti". STATO LISTEN Se attiva e il socket remoto e' specificato, allora cambia la connessione da passiva ad attiva, e seleziona un ISS. Spedisce un segmento SYN, setta SND.UNA a ISS, SND.NXT a ISS+1. Entra nello stato SYN-SENT. I dati associati con la SEND possono essere spediti con il segmento SYN oppure accodatiper la trasmissione dopo essere entrati nello stati ESTABLISHED. Il bit di urgenza, se richiesto nel comando deve essere spedito con i segmenti di dati e deve essere spedito come risultato di questo comando. Se non c'e' spazio per accodare la richiesta, risponde con "errore: risorse insufficienti". Se il socker remoto non era specificato, allora restituisce "errore: socket remoto non specificato". [Page 54] September 1981 Transmission Control Protocol Functional Specification Chiamata OPEN STATO SYN-SENT STATOSYN-RECEIVED STATO ESTABLISHED STATO FIN-WAIT-1 STATO FIN-WAIT-2 STATO CLOSE-WAIT STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Restituisce "errore: la connessione esiste gia'". [Page 55] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata SEND Chiamata SEND STATO CLOSED (cioe', il TCB non esiste) Se l'utente non ha accesso a tale connessione, allora restituisce "errore: connessione illecita per questo processo". Altrimenti, restituisce "errore: la connessione non esiste". STATO LISTEN Se il socket remoto e' specificato, allora cambia la connessione da passiva ad attiva, e seleziona un ISS. Spedisce un segmento SYN, imposta SND.UNA a ISS SND.NXT a ISS+1. Entra nello stato SYN-SENT. I dati associati con la SEND possono essere spediti con un SYN oppure accodati per la trasmissione dopo essere entrati nello stato ESTABLISHED. Se il bit urgent era richiesto nel comando, deve essere spedito con i segmenti di dati e deve essere spedito come risultato di questo comando. Se non c'e' spazio per accodare la richiesta, risponde con "errore: risorse insufficienti". Se il socket Remoto non era specificato, allora restituisce "errore: socket remoto non specificato". STATO ESTABLISHED STATO CLOSE-WAIT Segmenta il buffer e lo spedisce con un acknowledgmnet (valore del riconoscimento = RCV.NXT). Se c'e' spazio insufficiente per memorizzare questo buffer, restituisce semplicemente "errore: risorse insufficienti". Se il flag urgent e' impostato, allora SND <- SND.NXT-1 e imposta l'urgent pointer nei segmenti uscenti. [Page 56] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata SEND STATO FIN-WAIT-1 STATO FIN-WAIT-2 STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Restituisce "errore: connessione in chiusura" e non serve la richiesta. [Page 57] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata RECEIVE Chiamata RECEIVE STATO CLOSED (cioe', il TCB non esiste) Se l'utente non ha accesso a tale connessione, restituisce "errore: connessione illecita per questo processo". Altrimenti restituisce "errore: la connessione non esiste". STATO LISTEN STATO SYN-SENT STATO SYN-RECEIVED Accoda per l'elaborazione dopo essere entrati nello stato ESTABLISHED. se non c'e' spazio per accodare questa richiesta, risponde con "errore: risorse insufficienti". STATO ESTABLISHED STATO FIN-WAIT-1 STATO FIN-WAIT-2 Se segmenti insufficienti in arrivo sono accodati per soddisfare la richiesta, accoda la richiesta. Se non c'e' spazio di cod per memorizzare la RECEIVE, risponde con "errore: risorse insufficienti". Riassembla i segmenti in arrivo accodati nel buffer del ricevente e lo restituisce all'utente. Segna il "push visto" (PUSH) se e' il caso. Se il RCV.UP e' in anticipo dei segmenti che sono attualmente passati all'utente informa l'utente della presenza di dati urgenti. Quando il TCP prende la responsabilita' di consegnare i dati all'utente questo fatto deve essre comunicato al ricevente attraverso un riconoscimento. La formazione di tale riconoscimento e' descritta nella discussione sotto riguardante l'elaborazione di un segmento in arrivo. [Page 58] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata RECEIVE STATO CLOSE-WAIT Poiche' il lato remoto ha gia' spedito un FIN, le RECEIVE devono essere soddisfatte da il testo gia' alla mano, ma non ancora consegnato all'utente. Se nessun testo sta attendendo la consegna, la RECEIVE otterra' "errore: chiusura dela connessione" come risposta. Altrimenti, ogni testo rimanente puo' essere usato per soddisfare la RECEIVE. STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Restituisce "errore: chiusura della connessione". [Page 59] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata CLOSE Chiamata CLOSE STATO CLOSED (cioe', il TCB non esiste) Se l'utente non ha accesso a tale connessione, restituisce "errore: connessione illecita per questo processo". Altrimenti, restituisce "errore: la connessione non esiste". STATO LISTEN Ogni RECEIVE speciale e' restituita con risposta "errore: in chiusura". Cancella il TCB, entra nello stato CLOSED, e ritorna. STATO SYN-SENT Cancella il TCB e restituisce la risposta "errore: in chiusura" ad ogni SEND, o RECEIVE accodata. STATO SYN-RECEIVE Se nessuna SEND e' stata richiamata e non ci sono dati in corso da spedire, allora crea un segmento FIN e lo spedisce, e entra nello stato FIN-WAIT-1; altrimenti lo accoda per l'elaborazione dopo essere nello stato ESTABLISHED. STATO ESTABLISHED Accoda questo finche' tutte le precedenti SEND sono state segmentate. allora crea un segmento FIN e lo spedisce. In ogni caso, entra nello stato FIN-WAIT-1 STATO FIN-WAIT-1 STATO FIN-WAIT-2 Strettamente parlando, questo e' un errore e dovrebbe riceve un risposta del tipo "errore: chiusura della connessione". Una risposta "ok" sarebbe accettabilie, anche, finche' un secondo FIN e' emesso (il primo FIN puo' anche essere ritrasmesso). [Page 60] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata CLOSE STATO CLOSE-WAIT Accoda questa richieste finche' tutte le SEND precedenti sono state segmentate; poi spedisce un segmento FIN, e entra nello stato CLOSING STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Risponde con "errore: chiusura della connessione". [Page 61] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata ABORT Chiamata ABORT STATO CLOSED (cioe', il TCB non esiste) Se l'utente non avrebbe accesso a questa connessione, restituisce "errore: connessione illecita per questo processo". Altrimenti restituisce "errore: la connessione non esiste". STATO LISTEN Qualsiasi RECEIVE speciale dovrebbe rispondere con "errore: connessione riavviata". Cancella il TCV, entra nello stato CLOSED, e ritornare. STATO SYN-SENT Tutti le SEND e RECEIVE accodate dovrebbero dare la notifica "connessione riavviata", cancellare il TCB, entrare nello stato CLOSED, e ritornare. STATO SYN-RECEIVED STATO ESTABLISHED STATO FIN-WAIT-1 STATO FIN-WAIT-2 STATO CLOSE-WAIT Spedisce un segmento reset: Tutte le SEND e RECEIVE accodate dovrebbero dare la notifica "connessione riavviata"; tutti i segmenti accodati per la trasmissione (eccetto per i RST creati sopra) o ritrasmissione dovrebbero essere fluiti, cancellano il TCB, entrano nello stato CLOSED, e ritornano. STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Risponde con "ok" e cancella il TCB, entra nello stato CLOSED, e ritorna. [Page 62] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funziomanento Chiamata STATUS Chiamata STATUS STATO CLOSED (cioe', il TCB non esiste) Se l'user non ha accesso a tale connessione, restituisce "errore: connessione illecita per questo processo". Altrimenti restituisce "errore: la connessione non esiste". STATO LISTEN Restituisce "stato = LISTEN", e il puntatore al TCB. STATO SYN-SENT Restituisce "stato = SYN-SENT", e il puntatore al TCB. STATO SYN-RECEIVED Restituisce "stato = SYN-RECEIVE", e il puntatore al TCB. STATO ESTABLISHED Restituisce "stato = ESTABLISHED", e il puntatore al TCB. STATO FIN-WAIT-1 Restituisce "stato = FIN-WAIT-1", e il puntatore al TCB. STATO FIN-WAIT-2 Restituisce "stato = FIN-WAIT-2", e il puntatore al TCB. STATO CLOSE-WAIT Restituisce "stato = CLOSE-WAIT", e il puntatore al TCB. STATO CLOSING Restituisce "stato = CLOSING", e il puntatore al TCB. STATO LAST-ACK Restituisce "stato = LAST-ACK", e il puntatore al TCB. [Page 63] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento Chiamata STATUS STATO TIME-WAIT Restituisce "stato = TIME-WAIT", e il puntatore al TCB. [Page 64] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVO di SEGMENTI ARRIVO di SEGMENTI Se lo stato e' CLOSED (cioe', il TCB non esiste) allora tutti i dati nel segmento in arrivo sono scartati. Un segmento in arrivo contente un RST e' scartato. Un segmento in arrivo che non contiene un RST causa l'invio di un RST in risposta. I campi di riconoscimento e sequenza sono impostati per rendere la sequenza del reset accettabile al TCP che invio' i segmento sbagliati. Se il bit ACK non e' settato, e' usato il sequence number zero, Se il bit ACK e' settato, Ritorna. Se lo stato e' LISTEN allora prima controlla per un RST Un RST in arrivo dovrebbe essere ignorato. Ritorna. secondo, controlla per un ACK Ogni acknowledgmnet e' cattivo se esso arriva in una connessione ancora nello stato LISTEN. Un segmento reset accettabile dovrebbe essere creato per ogni segmento ACK-bearing che arriva. Il RST dovrebbe essere formato come di seguito: Ritorna. Terzo, controlla per un SYN Se il bit SYN e' impostato, controlla la sicurezza. Se la sicurezza/compartimento nel segmento in arrivo non coincide esattamente con la sicurezza/compartimento nel TCB allora invia un reset e ritorna. [Page 65] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVO di SEGMENTI Se il SEG.PRC e' piu' grande del TCB.PRC allora se l'utente e il sistema lo ammettono, imposta TCB.PRC<-SEG.PRC, se non lo permettono invia un reset e ritorna. Se il SEG.PRC e' minore del TCB.PRC allora continua. Imposta il RCV.NXT a SEG.SEQ+1, il IRS e' impostato a SEG.SEQ e ogni altro controllo o testo dovrebbe essere accodato per essere elaborato successivamente. il ISS dovrebbe essere selezionato e un segmento SYN inviato della forma: Il SND.NXT e' impostato a ISS+1 e il SND.UNA a ISS. Lo stato della connessione dovrebbe cambiare in SYN-RECEIVED. Nota che ogni altro controllo in arrivo o dati (combinato con il SYN) sara' elaborato nello stato SYN-RECEIVED, ma l'elaborazione di SYN e ACK non dovrebbe essere ripetuta. Se il LISTEN non e' stato completamente specificato (cioe', il socket remoto non era pienamente specificato), allora i campi non specificato dovrebbero essere riempiti adesso. quattro altri testi o controli Ogni altri segmento di controllo o text-bearing (non contenente SYN) deve avere un ACK e in questo modo sara' scartato dall'elaborazione dei ACK. Un segmento RST in arrivo non ha potuto essere valido, poiche' non potrebbe essere trasmesso in risposta a qualche cosa trasmessa attraverso questa incarnazione della connessione. Cosi' e' improbabile di arrivare qui, ma se si', esclude il segmento, e ritorna. Se lo stato e' SYN-SENT allora prima controlla il bit ACK Se il bit ACK e' impostato SE il SEG.ACK =< ISS, oppure SEG.ACK > SND.NXT, invia un reset (a meno che il bit RST sia impostato, se cosi', esclude il segmento e ritorna) e scarta il segmento. Ritorna. Se SND.UNA =< SND.NXT allora l'ACK e' accettabile. secondo, controlla il bit RST [Page 66] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVI di SEGMENTO Se il bit RST e' impostato Se l'ACK era accettabile allora segnala all'utente "errore: connessione riavviata", esclude il segmento, entra nello stato CLOSED, cancella il TCB, e ritorna. Altrimenti (nessun ACK) esclude il segmento e ritorna. terzo, controlla la sicurezza e la precedenza Se la sicurezza/compartimento nel segmento non coincide esattamente con la sicurezza/compartimento del TCB, invia un reset. Se c'e' un ACK Altrimenti Se c'e' un ACK La precedenza nel segmento deve coincidere con la precedenza nel TCB, se non e' cosi', invia un reset Se non c'e' alcun ACK Se la precedenza nel segmento e' maggiore della precedenza nel TCB allora ser l'utente e il sistema lo permettono, aumenta la precedenza nel TCB quella del segmento, se non permettono di aumentare la precedenza, invia un reset. Se la precedenza nel segmento e' minore della precedenza nel TCB, continua. Se fu spedito un reset, scarta il segmento e ritorna. quarto, controlla il bit SYN Questo punto dovrebbe essere raggiunto solo se l'ACK e' okay, oppure non c'e' alcun ACK, e il segmento non contiene un RST. Se il bit SYB e' impostato e la sicurezza/compartimento e la [Page 67] September 1981 Protocollo di Controllo della Tramissione Specifiche di Funzionamento ARRIVO di SEGMENTI precedenza sono accettabili, allora, il RCV.NXT e' impostato a SEG.SEQ+1, il IRS e' impostato a SEG.SEQ. Il SND.UNA dovrebbe essere aumentato per essere uguale al SEG.ACK (ce c'e' un ACK), e ogni segmento nella coda di ritrasmissione i quali sono quindi riconosciuti, dovrebbero essere rimossi. Se il SND.UNA > ISS (il nostro SYN e' stato riconosciuto), cambia lo stato della connessione a ESTABLISHED, crea un segmento ACK e lo spedisce, Dati o controlli che furono accodati per la trasmissione possono essere inclusi. Se ci sono altri controlli o testo nel segmento allora continua l'elaborazione al punto sotto numero sei, dove il bit URG e' verificato, altrimenti ritorna. Altrimenti entra nello stato SYN-RECEIVED, crea un segmento SYN,ACK e lo spedisce. Se ci sono altri controlli o testo nel segmento, li accoda per l'elaborazione dopo che lo stato ESTABLISHED e' stato raggiunto, e ritorna. quinto, se nessuno dei bit SYN o RST sono impostati allora esclude il segmento e ritorna. [Page 68] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVI di SEGMENTI Altrimenti, prima controlla il numero di sequenza STATO SYN-RECEIVED STATO ESTABLISHED STATO FIN-WAIT-1 STATO FIN-WAIT-2 STATO CLOSE-WAIT STATO CLOSING STATO LAST-ACK STATO TIME-WAIT I segmenti sono elaborati in sequenza. Verifiche iniziali all'arrivo sono effettuate per scartare i vecchi duplicati, ma un'ulteriore elaborazione e' fatta nell'ordine SEG.SEQ. Se il contenuto di un segmento sorpassa il limite tra vecchio e nuovo, solo nuove parti dovrebbero essere elaborate. Ci sono quattro casi per la verifica di accettazione di un segmento in arrivo: Lunghezza Window Verifica Segmento Ricevuta ------- ------- ------------------------------------------- 0 0 SEG.SEQ = RCV.NXT 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >0 0 non accettabile >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND Se il RCV. WND e' zero, nessun segmento sara' accettato, ma permessi speciali possono essere fatti per accettare ACK, URG, e RST validi. Se un segmento in arrivo non e' accettabile, un riconoscimento dovrebbe essere spedito in risposta (a meno che il bit RST sia impostato, se e' cosi', eslcude il segmento e ritorna): Dopo avere spedito il riconoscimento, esclude il segmento non accettabile e ritorna. [Page 69] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVI di SEGMENTI Di seguito e' supposto che il segmento e' il segmento idealizzato che inizia a RCV.NXT e non supera la window. Uno ha potuto adattare i segmenti attuali per realizzare questo presupposto tagliando fuori ogni porzione che si trova fuori dalla window (inclusi i SYN e i FIN), e soltanto procedendo ulteriormente se il segmento inizia a RCV.NXT, I segmenti con numeri di sequenza maggiori possono essere tenuti per elaborazioni successive. secondo, controlla il bit RST, STATO SYN-RECEIVED Se il bit RST e' impostato Se questa connessione era inziata con una OPEN passiva (cioe', proviene dallo stato LISTEN), allora restituisce questa connessione allo stato LISTEN e ritorna. L'utente non necessita di essere informato. Se la connessione era iniziata come una OPEN attiva (cioe', proviene dallo stato SYN-SENT) allora la connessione e' rifiutata, e avvisa l'utente con "connessione rifiutata". In un caso o nell'altro, tutti i segmenti nella coda di ritrasmissione dovrebbero essere rimossi. E nel caso della OPEN attiva, entra nello stato CLOSED, cancella il TCB, e ritorna, ESTABLISHED FIN-WAIT-1 FIN-WAIT-2 CLOSE-WAIT Se il bit RST e' impostato, allora, ogni RECEIVE o SEND speciale dovrebbe riceve risposte di "reset". Tutti i segmenti accodati dovrebbero essere fluiti. Gli utenti dovrebbero anche ricevere un segnale generale non sollecitato "connessione riavviata". Entra nello stato CLOSED, cancella il TCB, e ritorna. STATO CLOSING STATO LAST-ACK TIME-WAIT Se il bit RST e' impostato, entra nello stato CLOSED, cancella il TCB, e ritorna. [Page 70] September 1981 Protocollo di Controllo della Tramissione Specifiche di Funziomanento ARRIVI di SEGMENTI terzo controlla la sicurezza e la precedenza SYN-RECEIVED Se la sicurezza/compartimento e la precedenza nel segmento non coincidono esattamente con la sicurezza/compartimento e la precedenza nel TCB, allora invia un reset, e ritorna. STATO ESTABLISHED Se la sicurezza/compartimento e la precedenza nel segmento non coincidono esattamente con la sicurezza/compartimento e la precedenza nel TCB, allora invia un reset, ogni RECEIVE e SEND speciale dovrebbe ricevere le risposte "reset". Tutti i segmenti accodati dovrebbero essere fluiti. Gli utenti dovrebbero inoltre ricevere un segnale generale non sollecitato "connessione riavviata". Entra nello stato CLOSED, cancella il TCB, e ritorna, Nota che questo controlla e' posto successivamente al controllo della sequenza per evitare che un segmento proveniente da una vecchia connessione tra queste porte con differente sicurezza oppure precedenza causi la sospensione della connessione attuale. quarto, controlla il bit SYN, SYN-RECEIVED STATO ESTABLISHED FIN-WAIT STATE-1 FIN-WAIT STATE-2 STATO CLOSE-WAIT STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Se il SYN e' nella window e' un errore, invia un reset, ogni RECEIVE e SEND speciale dovrebbe ricevere la risposta "reset", tutti i segmenti accodati dovrebbero essere fluiti, l'utente dovrebbe inoltre ricevere un segnale generale non sollecitato "connessione riavviata", entra nello stato CLOSED, cancella il TCB, e ritorna. Se il SYN non e' nella window questo punto non sara' raggiunto e un ack fosse stato trasmesso nel primo punto (controllo del numero di sequenza). [Page 71] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVO di SEGMENTI quinto, controlla il campo ACK, se il bit ACK non e' settato, esclude il segmento e ritorna se il bit ACK e' settato STATO SYN-RECEIVED Se SND.UNA =< SEG.ACK =< SND.NXT allora entra nello stato ESTABLISHED e continua l'elaborazione. Se il segmento di riconoscimento non e' accettabile, crea un segmento reset, e lo spedisce. STATO ESTABLISHED Se SND.UNA < SEG.ACK =< SND.NXT allora imposta SND.UNA <- SEG.ACK. Ogni segmento nella coda di ritrasmissione i quali sono in questo modo riconosciuti interamente sono rimossi. Gli utenti dovrebbero ricevere riconoscimenti positivi per i buffer che sono stati TRASMESSI e pienamente riconosciuti (cioe', il buffer TRASMESSO dovrebbe ritornare con un risposta "ok"). Se l'ACK e' un duplicato (SEG.ACK < SND.UNA), puo' essere ignorato. Se l'ACK riconosce qualcosa non ancora spedito (SEG.ACK > SND.NXT) allora invia un ACK, esclude il segmento, e ritorna. Se SND.UNA < SEG.ACK =< SND.NXT, la window inviata dovrebbe essere aggiornata. Se (SND.WL1 < SEG.SEQ oppure (SND.WL1 = SEG.SEQ e SND.WL2 =< SEG.ACK)), imposta SND.WND <- SEG.WND, imposta SND.WL1 <- SEG.SEQ, e setta SND.WL2 <- SEG.ACK. Nota che SND.WND e' un offset da SND.UNA, che SND.WL1 registra il numero di sequenza dell'ultimo segmento usato per aggiornare SND.WND, e che SND.WL2 registra l'acknowledgment number dell'ultimo segmento usato per aggiornare SND.WND. Qui, il controllo previene l'uso di vecchi segmenti per aggiornare la window. [Page 72] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVI di SEGMENTI STATO FIN-WAIT-1 In aggiunta all'elaborazione per lo stato ESTABLISHED, se il nostro FIN e' ora riconosciuto allora entra in FIN-WAIT-2 e continua l'elaborazione in questo stato. STATO FIN-WAIT-2 In aggiunta all'elaborazione per lo stato ESTABLISHED, se la coda di ritrasmissione e' vuota, la CLOSE dell'utente puo' essere riconosciuta ("ok") ma non cancella il TCB. STATO CLOSE-WAIT Fa la stessa elaborazione dello stato ESTABLISHED STATO CLOSING In aggiunta all'elaborzione per lo stato ESTABLISHED, se l'ACK riconosce il nostro FIN allora entra nello stato TIME-WAIT, altrimenti ignora il segmento. STATO LAST-ACK La sola cosa che puo' arrivare in questo stato e' un riconoscimento del nostro FIN. Se il nostro FIN e' ora riconosciuto, cancella il TCB, entra nello stato CLOSED, e ritorna. STATO TIME-WAIT La sola cosa che puo' arrivare in questo stato e' una ritrasmissione del FIN remoto. Lo riconosce, e riavvia il timeout 2 MSL. sesto, controlla il bit URG. STATO ESTABLISHED STATO FIN-WAIT-1 STATO FIN-WAIT-2 Se il bit URG e' impostato, RCV.UP <- max(RCV.UP,SEG.UP), e avvisa l'utente che il lato remoto ha dati urgenti se il puntatore di urgenza (RCV.UP) e' in anticipo dei dati elaborati. Se l'utente e' gia' stato avvisato (o e' ancora nella "modalita' urgente") per questa sequenza continua di dati urgenti, non avvisa l'utente di nuovo. [Page 73] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVO di SEGMENTI STATO CLOSE-WAIT STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Questo non dovrebbe accdare, poiche' un FIN e' stato ricevuto dal lato remoto. Ignore l'URG. settimo, elabora il segmento di testo, STATO ESTABLISHED STATO FIN-WAIT-1 STATO FIN-WAIT-2 Una volta nello stato ESTABLISHED, e' possibile consegnare il segmento di testo ai buffer della chiamata utente RECEIVE. Il testo dai segmenti puo' essere spostato nel buffer finche' il buffer e' pieno oppure il segmento e' vuoto. Se il segmento svuota e trasporta un flag PUSH, allora l'utente e' informato, quando il buffer e' restituito, che un PUSH e' stato ricevuto. Quando il TCP prende la responsabilita' di consegnare i dati all'utente, esso deve anche riconoscere il ricevimento dei dati. Una volta che il TCP prende la responsabilita' dei data esso anticipa il RCV.NXT sopra i dati accettati, e aggiusta RCV.WND in modo appropriato alla disponibilita' corrente di buffer. Il totale di RCV.NXT e RCV.WND non dovrebbe essere diminuito. Notare i suggerimenti di gestione delle window nella sezione 3.7. Invia un riconoscimento della forma: Questo riconoscimento dovrebbe essere trasportato su un segmento essendo trasmesso, se possibile, senza incorrere ad un eccessivo ritardo. [Page 74] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVO di SEGMENTI STATO CLOSE-WAIT STATO CLOSING STATO LAST-ACK STATO TIME-WAIT Questo non dovrebbe accadere, poiche' un FIN e' stato ricevuto dal lato remoto. Ignora il segmento di testo. ottavo, controlla il bit FIN, Non processa il FIN se lo stato e' CLOSED, LISTEN oppure SYN-SENT poiche' il SEG.SEQ non puo' essere validato; esclude il segmento e ritorna. Se il bit FIN e' impostato, avvisa l'utente con "chiusura della connessione" e restituisce a ogni RECEIVE in corso lo stesso messaggio. aumenta il RCV.NXT sopra il FIN, e invia un riconoscimento per il FIN. Nota che il FIN include un PUSH perogni segmento di testo non ancora consegnato all'utente. STATO SYN-RECEIVE STATO ESTABLISHED Entra nello stato CLOSE-WAIT. STATO FIN-WAIT-1 Se il nostro FIN e' stato riconosciuto (forse in questo segmento), allora entra nel TIME-WAIT, avvia il timer time-wait, termina gli altri timer; altrimenti entra nello stato CLOSING. STATO FIN-WAIT-2 Entra nello stato TIME-WAIT. Avvia il timer time-wait, termina gli altri timer. STATO CLOSE-WAIT Rimane nello stato CLOSE-WAIT. STATO CLOSING Rimane nello stato CLOSING. STATO LAST-ACK Rimane nello stato LAST-ACK. [Page 75] September 1981 Protocollo di Controllo della Trasmissione Specifiche di Funzionamento ARRIVO di SEGMENTI STATO TIME-WAIT Rimane nello stato TIME-WAIT. Riavvia il timeout time-wait 2 MSL. e ritorna. [Page 76] September 1981 Protocollo di Controllo della Tramissione Specifiche di Funzionamento TIMEOUT dell'UTENTE TIMEOUT dell'UTENTE Per ogni stato in cui il timeout dell'utente termina, fluisce tutte le code, avvisa l'utente in generale con "errore: connessione sospesa a causa del timeout dell'utente" e per ogni chiamata speciale, cancella il TCB, entra nello stato CLOSED e ritorna. TIMEOUT di RITRASMISSIONE Per ogni stato in cui il timeout di ritrasmissione termina su un segmento nella coda di ritrasmissione, invia il segmento all'inizio della coda di ritrasmissione ancora, reinizializza il timer di ritrasmissione, e ritorna. TIMEOUT di TIME-WAIT Se il timeout del time-wait termina su una connessione, cancella il TCB, entra nello stato CLOSED e ritorna. [Page 77] September 1981 Protocollo di Controllo della Trasmissione [Page 78] September 1981 Protocollo di Controllo della Trasmisione GLOSSARIO 1822 BBN Report 1822, "Le Caratteristiche dell'Interconnessione di un Host e un IMP". Le caratteristiche di un interfaccia tra un host e l'ARPANET ACK Un bit di controllo (riconoscimento) che non occupa spazio di sequenza, il quale indica che il campo di riconoscimento di questo segmento specifica il prossimo numero di sequenza che il mittente di questo segmento si aspetta di ricevere, quindi riconoscendo la ricezione di tutti i numeri di sequenza precedenti. ARPANET message -- messaggio ARPANET L'unita' di trasmissione tra un host e un IMP nell'ARPANET. La dimensione massima e' circa 1012 otteti (8096 bit). ARPANET packet -- pacchetto ARPANET Una unita' di trasmissione usata internamente in ARPANET tra gli IMP. La dimensione massima e' circa 126 otteti (1008 bit). connection -- connessione Un percorso di collegamento virtuale identificato da un paio di socket. datagram -- datagramma Un messaggio inviato in una rete a commutazione di pacchetto. Destination Address -- Indirizzo di Destinazione L'indirizzo di destinazione, solitamente gli indentificatori della rete e dell'host. FIN Un bit di controllo (finis) che occupa un numero di sequenza, il quale indica che il mittente non spedira' altri dati o controlli che occupano spazio di sequenza. fragment -- frammento Una porzione di un unita' logica di dati, in particolare un frammento internet e' una porzione di un datagramma internet. FTP Un protocollo per il trasferimento di file. [Page 79] September 1981 Protocollo di Controllo della Trasmissione Glossario header -- intestazione Informazione di controllo all'inizio di un messaggio, segmento, frammento, pacchetto oppure blocco di dati. host Un computer. In particolare una risorsa o destinazione di messaggi dal punto di vista della comunicazione di rete. Identification -- Identificamento Un campo del Protocollo Internet. Questo valore di identificazione assegnato dal mittente, aiuto l'assemblamento dei frammenti di un datagramma. IMP Il Interface Message Processor, il paccheto commutato di ARPANET. internet address -- indirizzo internet Un indirizzo della sorgente o destinazione specificato a livello host. internet datagram -- datagramma internet L'unita' di dati scambiata tra un modulo internet e il protocollo di livello superiore, assieme con l'header internet. internet fragment -- frammento internet Una porzione di dati di un datagramma internet con un header internet. IP Protocollo Internet. IRS Il numero di Sequenza Iniziale del Ricevente. Il primo numero di sequenza usato dal mittente su una connessione. ISN Il Numero di Sequenza Iniziale. Il primo numero di sequenza usato su una connessione, (o l'ISS oppure l'IRS). Selezionato da una procedura di sincronizzazione. ISS Il numero di Sequenza iniziale Inviato. Il primo numero di sequenza usato dal mittente su una connessione. leader Informazione di controllo all'inizio di un messaggio oppure blocco di dati. In particolare, nell'ARPANT, l'informazione di controllo su un messaggio ARPANET all'interfaccia dell'host-IMP [Page 80] September 1981 Protocollo di Controllo della Trasmissione Glossario left sequence Questo e' il prossimo numero di sequenza a essere riconosciuto dai dati che ricevono il TCP (oppure il numero di sequenza piu' basso non attualmente riconosciuto) ed e' a volta definito come il bordo sinistro della window inviata. local packet -- pacchetto locale L'unita di trasmissione entro una rete locale. module -- modulo Una implementazione, solitamente nel software, di un protocollo oppure di un'altra procedura. MSL Maximum Segment Lifetime, il tempo che un segmento TCP puo' esistere nel sistema interconnesso. Arbitrariamente definito ad essere di 2 minuti. octet -- otteto Un byte di otto bit. Options -- Opzioni Un campo Option puo' contenere parecchie opzioni, e ogni opzione puo' essere lunga parecchi otteti. Le opzioni sono usate principalmente nelle situazioni di test; per esempio, per trasportare timestamp. Sia il Protocollo Internet che il TCP forniscono i campi delle opzioni. packet -- pacchetto Un pacchetto di dati con un header il quale puo' o non puo' essere completo logicalmente. Molto spesso un'impacchettamento fisico piuttosto che un impacchettamento logico dei dati. port -- porta La parte di un socket che specifica quale input logico oppure canale di output di un processo e' associato con i dati. process -- processo Un programma in esecuzione. Un mittente oppure una destinazione dal punto di vista del TCP oppure altri protocolli host-a-host. PUSH Un bit di controllo che non occupa nessun spazio di sequenza, indica che questo segmento contiene dati che devono essere spinti attraverso verso l'utente ricevente. RCV.NXT prossimo sequence number ricevuto [Page 81] September 1981 Protocollo di Controllo della Trasmissione Glossario RCV.UP urgent pointer ricevuto RCV.WND window ricevuta prossimo sequence number ricevuto Questo e' il prossimo sequence number che il TCP prevede di ricevere. window ricevuta Questo rappresenza i sequence number che il TCP (ricevente) locale e' pronto a ricevere. In questo modo, il TCP locale considera che segmenti sconfinanti con il campo RCV.NXT a RCV.NXT + RCV.WND - 1 trasporta dati o controlli accettabili. I segmenti contenenti sequence number interamente fuori da questo campo sono considerati duplicati e scartati. RST Un bit di controllo (reset), che non occupa sequence space, indica che il ricevente dovrebbe cancellare la connessione senza ulteriori interazioni. Il ricevente puo' determinare, basandosi sui sequence numbers e i campi acknowledgment del segmento in arrivo, se dovrebbe rispettare il comando reset oppure ignorarlo. In nessun caso fa una ricevuta del segmento contenente un RST che causa un RST in risposta. RTP Protocollo Real Time: Un protocollo host-a-host per la comunicazione di informazione critiche. SEG.ACK segmento acknowledgment SEG.LEN dimensione segmento SEG.PRC valore della precedenza del segmento SEG.SEQ segmento sequence SEG.UP puntatore di urgenza nel campo del segmento [Page 82] September 1981 Protocollo di Controllo della Trasmissione Glossario SEG.WND campo window del segmento segment -- segmento Una unita' logica di dati, in particolare un segmento TCP e' l'unita di dati trasferita tra un paio di moduli del TCP. segment acknowledgment --segmento acknowledgment Il sequence number nel campo acknowledgment del segmento in arrivo. segment length -- dimensione del segmento L'ammontare del sequence number space occupato da un segmento, includendo ogni controllo che occupa sequence space. segment sequence -- segmento di sequenza Il numero nel campo della sequenza di un segmenti in arrivo. send sequence -- sequenza di invio Questo e' il prossimo sequence number che il TCP locale (mittente) usera' sulla connessione. E' inizialmente selezionato da un initial sequence number curve (ISN) ed e' incrementato per ogni otteto di dati o controllo ordinato spedito. send window -- window di invio Rappresenta i sequence number che il TCP (remoto) ricevente e' pronto a ricever. E' il valore del campo della window specificato nei segmenti provenienti dal TCP remoto (ricevente dei dati). La gamma di nuovi sequence number che possono essere emessi dal TCP vanno da SND.NXT a SND.UNA + SND.WND -1. (La ritrasmissione di sequence number tra SND.UNA e SND.NXT, sono previste, ovviamente.) SND.NXT sequenza di invio SND.UNA sequenza di sinistra SND.UP puntatore di urgenza di invio SND.WL1 segment sequence number all'ultima window aggiornata SND.WL2 segment acknowldgment number all'utima window aggiornata [Page 83] September 1981 Protocollo di Controllo della Trasmissione Glossario SND.WND window di invio socket Un indirizzo che include un indetificatore di porta, cioe', la concatenazione di un Indirizzo Internet con una porta TCP. Source Address -- Indirizzo del Mittente L'indirizzo sorgente, solitamente gli identificatori della rete e di host. SYN Un bit di controllo nel segmento in arrivo, che occupa un sequence number, usato all'iniziazione di una connessione, per indicare dove la numerazione di sequenza partira'. TCB Transmission control block, la struttura dei dati che registra lo stato di una connessione. TCB.PRC La precedenza della connessione. TCP Protocollo di Controllo della Tramissione: Un protocollo host-a-host per la comunicazione affidabile in ambienti interconnessi. TOS Type Of Service, un campo del Protocollo Internet. Type of Service -- Tipo di Servizio Un campo del Protocollo Internet che indica il tipo di servizio per questo frammento internet. URG Un bit di controllo (urgent), che non occupa sequence space, usato per indicare che l'utente ricevente dovrebbe essere avvisato per fare l'elaborazione urgente finche' ci sono dati da essere elaborati con sequence number minori del valore indicato nel puntatore di urgenza. urgent pointer -- puntatore di urgenza Un campo di controllo importante solo quando il bit URG e' settato. Questo campo comunica il valore del puntatore di urgenza il quale indica gli otteti dei dati associati con la chiamata urgent dell'utente mittente. [Page 84] September 1981 Protocollo di Controllo della Trasmissione REFERENZE [1] Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974. [2] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981. [3] Dalal, Y. and C. Sunshine, "Connection Management in Transport Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473, December 1978. [4] Postel, J., "Assigned Numbers", RFC 790, USC/Information Sciences Institute, September 1981. ----------- z3r0Jym '05