Di fatti si tende ad ignorare completamente la complicatezza eventuale al di sotto di questa importante interfaccia. Dal punto di vista dell' applicativo i livelli sottostanti nel loro insieme vengono detti Dominio di Comunicazione. Il Porto e' un concetto di punto di aggancio tra l'applicativo e il dominio di comunicazone.
L'implementazione piu' comune dei protocolli TCP/IP e' quella di Berkeley. In tale implementazione l'interfaccia tra gli applicativi e il dominio di comunicazione e' resa da una libreria in Linguaggio C, la Berkeley Socket Interface.
Il concetto di porto viene reso con una struttura C opaca, il socket, e gestito tramite funzioni che manipolano tale struttura. L'uso dell'interfaccia dei socket, dal punto di vista del programmatore, ricorda molto l'uso dei files in linguaggio C. Un porto ed un socket possono quindi venire interscambiati come concetti pratici.
All'atto dell'apertura di un socket viene determinato il protocollo di trasporto da usare (TCP o UDP) e il tipo di dominio di comunicazione. UNIX ne supporta due:
Ad un socket aperto e' associato un numero identificativo o handle, che viene detto il numero del porto.
Il Server inizia la sua vita aprendo un porto ben conosciuto, ovvero con un numero identificativo noto a tutti e ben preciso. Esiste una tabella detta services che associa il nome del servizio standard (il nome del processo server) al porto conosciuto e al protocollo di trasporto usato. Tale tabella deve essere presente in tutte le macchine che usano applicativi client-server TCP/IP, di solito viene fornita con la release dei protocolli per una data macchina ed e' comunque recuperabile in versione aggiornata dall'Internet.
Il server si pone quindi in ascolto di richieste di collegamento provenienti dal dominio di comunicazione. Si dice che il server ascolta sul suo porto assegnato.
Alla ricezione di una richiesta di collegamento proveniente dalla rete (originata da un client) il server esegue una chiamata di sistema fork e si spezza in due processi, detti padre e figlio:
Per ovviare al tempo discreto di esecuzione della fork, durante il quale possono arrivare delle altre richieste al server dalla rete, il sistema operativo associa ad ogni porto una piccola coda FIFO, tipicamente di cinque elementi.
Il Client viene attivato dalla volonta' di un essere umano e corrisponde al processo applicativo che interagisce con l'umano. E' il client che prende l'iniziativa di apertura dell'istanza di comunicazione col server.
Il client apre un porto effimero. Quindi, consultando l'opportuna tabella services determina il numero di porto del server da contattare.
La quadrupla di informazioni:
univocamente determina una istanza di comunicazione.
Il client tramite opportuna funzione con tali argomenti richiede l'apertura di una connessione. Se ha successo, la funzione ritorna una struttura contenente l'informazione sull'effettivo porto di servizio del server.
Il client quindi conduce l'interazione secondo il protocollo applicativo del servizio, con cui e' stato programmato. Il client normalmente prende l'iniziativa anche di chiusura della connessione, a meno che non si verifichino errori, e chiude infine il suo porto effimero, prima di morire come processo.
Anche se e' stata descritta la sequenza di operazioni propria di un modo a connessione, il modo senza connessione funziona in maniera molto simile.
Per ovviare al problema di troppi server in esistenza simultanea in un dato sistema operativo, TCP/IP introduce l'idea di un superserver il cui nome in UNIX e' inetd.
Il superserver consulta un suo File di Configurazione, inetd.conf, ed apre tanti porti di ascolto ben conosciuti quanti sono i server amministrati.
Alla ricezione di un tentativo di apertura di connessione su uno di tali porti, il superserver emette due chiamate di sistema, fork ed exec e genera lo specifico processo server richiesto. Questi apre un porto effimero e porta avanti l'istanza di comunicazione come nel precedente caso di processo server figlio.
Anche se il tempo richiesto per la doppia chiamata di sistema e' piu lungo (tempo che viene ridotto se il sistema operativo fa' uso di threads anziche' di processi), il sistema nel suo complesso e' piu' efficiente avendo meno processi attivi in memoria.
Questo sistema fornisce anche la possibilita' che il superserver invochi un processo intermedio di monitor o di filtro, prima dell'invocazione del server richiesto, che esegue funzioni di certificazioni di sicurezza e consente o meno la connessione.
Non tutti i server sevono peraltro essere amministrati dal superserver: possono sempre sussistere dei server standalone se hanno traffico di richieste notevole (p.es. il server HTTP del Web).