From: Simone Piccardi Date: Sat, 31 Mar 2001 22:45:18 +0000 (+0000) Subject: Poche modifiche nei ritagli di tempo. X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=e323f7e103dac7a264d3ef335d23540719df2623;p=gapil.git Poche modifiche nei ritagli di tempo. --- diff --git a/Makefile b/Makefile index aa05f50..988431e 100644 --- a/Makefile +++ b/Makefile @@ -1,3 +1,5 @@ + + clean: rm -f *.dvi *.log *.ps *.html \ No newline at end of file diff --git a/network.tex b/network.tex index ba0e7d3..531d731 100644 --- a/network.tex +++ b/network.tex @@ -11,6 +11,42 @@ quello che sta alla base di internet, ed in particolare sulle parti pi importanti ai fini della programmazione. +\section{Il modello client-server} +\label{sec:net_cliserv}. + +La differenza principale fra un'applicazione di rete e un programma normale è +che quest'ultima per definizione concerne la comunicazione fra ``processi'' +diversi (che in generale non girano neanche sulla stessa macchina). Questo già +prefigura un cambiamento completo rispetto all'ottica del ``programma'' +monolitico all'interno del quale vengono eseguite tutte le istruzioni, e +presuppone un sistema operativo ``multitasking'' in grado di eseguire processi +diversi. + +Il concetto fondamentale si basa la programmazione di rete sotto Linux (e +sotto Unix in generale) è il modello \textit{client-server} in cui un +programma di servizio, il \textit{server} riceve un connessione e risponde a +un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un +definito insieme di servizi. + +Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni +servizio che viene fornito tramite la rete, ma il modello è utilizzato in +generale anche per programmi di uso locale. + +Normalmente si dividono i server in due categorie principali, +\textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento. + +Un server iterativo risponde alla richiesta inviando i dati e resta occupato +(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la +richiesta. Una volta completata la richiesta il server diventa di nuovo +disponibile. + +Un server concorrente al momento di trattare la richiesta crea un processo +figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di +ulteriori richieste. In questo modo più richieste possono essere soddisfatte +contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro +viene terminato, mentre il server originale resta sempre attivo. + + \section{I protocolli di rete} \label{sec:net_protocols} @@ -190,6 +226,12 @@ rete (locale) a basso livello, un uso quindi molto specialistico. Il livello 1 invece dipende dalle singole applicazioni ed è di nuovo troppo specifico per essere affrontato qui. +In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP, +ma ci concentreremo principalmente sul livello di trasposto e in particolare +sul protocollo TCP sia per il ruolo centrale che esso svolge nella maggior +parte delle applciazioni, sia per la sua complessità che necessita di maggiori +spiegazioni. + \subsection{Il quadro generale} Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da @@ -280,8 +322,8 @@ internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i problemi si è perciò definita una nuova versione del protocollo, che (saltando un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di IPv4, mantendone inalterate le funzioni che si sono dimostrate valide, -eliminando quelle inutili e aggiungendone poche altre ponendo al contempo una -grande attenzione a mantenere il protocollo il più snello e veloce possibile. +eliminando quelle inutili e aggiungendone poche altre per mantenere il +protocollo il più snello e veloce possibile. I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a grandi linee nei seguenti punti: @@ -313,57 +355,117 @@ Per maggiori dettagli riguardo al protocollo si pu \label{sec:net_udp} UDP è un protocollo di trasporto molto semplice, la sua descizione completa è -contenuta dell'RFC768, ma in sostanza esso è una semplice interfaccia a IP dal +contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al protocollo) su un -socket, al pacchetto viene aggiunto un header molto semplice -(\ref{sec:appA_udp}, e poi viene passato al livello superiore (IPv4 o IPv6 -che sia) che lo spedisce verso la destinazione. Dato che né IPv4 né IPv6 -garantiscono l'affidabilità niente assicura che il pacchetto arrivi a -destinazione, né che più pacchetti arrivino nello stesso ordine in cui sono -stati spediti. +socket, al pacchetto viene aggiunto un header molto semplice (per una +descrizione più accurata vedi \ref{sec:appA_udp}), e poi viene passato al +livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione. +Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il +pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso +ordine in cui sono stati spediti. Pertanto il problema principale che si affronta quando si usa UDP è la -mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino - +mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a +destinazione occorrerà provvedere con l'applicazione all'interno della quale +si dovrà inserire tutto quanto necessario a gestire la notifica di +ricevimento, la ritrasmissione, il timeout. + +Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello +stesso ordine in cui sono stati trasmessi, e può anche accadere che i +pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto +questo di nuovo deve tenere conto l'applicazione. + +Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la +destinazione esso viene passato all'applicazione ricevente in tutta la sua +lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza +viene anche essa trasmessa all'applicazione all'atto del ricevimento. + +Infine UDP è un protocollo che opera senza connessione +(\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di +relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni +in cui un client può scrivere su uno stesso socket pacchetti destinati a +server diversi, o un server ricevere su un socket paccetti provenienti da +client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è +quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più +stazioni usando la stessa frequenza. + +Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il +grande pregio della velocità che in certi casi è essenziale; inoltre si presta +bene per le applicazioni in cui la connessione non è necessaria e +costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può +essere tollerata, come quelle che usano il multicasting. \subsection{TCP: Transport Control Protocol)} \label{sec:net_tcp} +Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente +diverso da UDP; alla base del suo design infatti non stanno semplicità e +velocità, ma la ricerca della massima affidabilità possibile nella +trasmissione dei dati. + +La prima differenza con UDP è che TCP provvede sempre una conessione diretta +fra un client e un server, attraverso la quale essi possono comunicare; per +questo il paragone più appropriato per questo protocollo è quello del +collegamento telefonico, in quanto prima viene stabilita una connessione fra +due stazioni su cui poi viene effettuata una comunicazione diretta. + +Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono +inviati attraverso una connessione ne viene richiesto un ``ricevuto'' +(il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno +ritrasmessi facendo un determinato numero di tentativi intervallati da un +periodo di tempo crescente, fintanto che la connessione sarà considerata +fallita o caduta la connessione (con un errore di \textit{time-out}), dopo un +periodo di tempo che dipende dall'implementazione e che può variare far i +quattro e i dieci minuti. + +Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea +di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del +tempo di andata e ritorno dei pacchetti (il cosiddetto RTT, +\textit{round-trip time}) fra un client e un server che lo rende in grado di +adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o +cadere facilmente in timeout. + +Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di +sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000 +bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due +segmenti (le unità di dati passate da TCP a IP vengono chiamate +\textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di +sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se +i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano +più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto, +all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati. + +Il protocollo provvede anche un controllo di flusso (\textit{flow control}), +cioè specifica sempre all'altro capo della trasmissione quanti dati può +ricevere tramite una \textit{advertised window} (letteralmente finestra +annunciata), che indica lo spazio disponibile nel buffer di ricezione, +cosicchè nella trasmissione non vengano inviati più dati di quelli che possono +essere ricevuti. + +Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal +socket ed aumentando con la lettura di quest'ultimo da parte +dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non +verranno accettati altri dati. Si noti che UDP non provvede niente di tutto +ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il +ricevitore non può sostenere. + +Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese +\textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo +stesso tempo, il che poi comporta che quanto dicevamo a proposito del +controllo di flusso e della gestione della sequenzialità dei dati viene +effettuato per entrambe le direzioni di comunicazione. + +\subsection{Creazione e terminazione della connessione TCP} + +Per capire il funzionamento delle funzioni della interfaccia dei socket che +operano con TCP (come \texttt{connect}, \texttt{accept} e \texttt{close} che +vedremo più avanti) è fodamentale capire come funziona la creazione e la +conclusione di una connessione TCP. + + + + +\subsection{Le porte} -\section{Il modello client-server} -\label{sec:net_cliserv}. - -La differenza principale fra un'applicazione di rete e un programma normale -è che quest'ultima per definizione concerne la comunicazione fra -``processi'' diversi (che in generale non girano neanche sulla stessa -macchina). Questo già prefigura un cambiamento completo rispetto all'ottica -del ``programma'' monolitico all'interno del quale vengono eseguite tutte le -istruzioni, e presuppone un sistema operativo ``multitasking'' in grado di -eseguire processi diversi. - -Il concetto fondamentale si basa la programmazione di rete sotto Linux (e -sotto Unix in generale) è il modello \textit{client-server} in cui un -programma di servizio, il \textit{server} riceve un connessione e risponde a -un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un -definito insieme di servizi. - -Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni -servizio che viene fornito tramite la rete, ma il modello è utilizzato in -generale anche per programmi di uso locale. - -Normalmente si dividono i server in due categorie principali, -\textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento. - -Un server iterativo risponde alla richiesta inviando i dati e resta occupato -(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la -richiesta. Una volta completata la richiesta il server diventa di nuovo -disponibile. - -Un server concorrente al momento di trattare la richiesta crea un processo -figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di -ulteriori richieste. In questo modo più richieste possono essere soddisfatte -contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro -viene terminato, mentre il server originale resta sempre attivo. - diff --git a/socket.tex b/socket.tex index 786ed55..4cc999d 100644 --- a/socket.tex +++ b/socket.tex @@ -1,12 +1,16 @@ \chapter{Socket} \label{cha:socket} -I \textit{socket} sono usati come meccanismo di comunicazione fra programmi -utilizzato in ambito unix (e non solo). La creazione di un socket restituisce -un file descriptor analogo a quello di una pipe ma a differenza di questa e -degli altri meccanismi esaminati nel capitolo \ref{cha:ipc} i socket non sono -limitati alla comunicazione fra processi che girano sulla stessa macchina ma -possono effettuare la comunicazione anche attraverso la rete. +Il \textit{socket} (traducibile liberamente come \textsl{manicotto}) è uno dei +principali meccanismi di comunicazione fra programmi utilizzato in ambito unix +(e non solo). Il socket costituisce in sostanza un canale di comunicazione fra +due processi su cui si possono leggere e scrivere dati. + +La creazione di un socket restituisce un file descriptor con un comportamento +analogo a quello di una pipe ma a differenza di questa e degli altri +meccanismi esaminati nel capitolo \ref{cha:ipc} i socket non sono limitati +alla comunicazione fra processi che girano sulla stessa macchina ma possono +effettuare la comunicazione anche attraverso la rete. I socket infatti sono la principale API (\textit{Application Program Interface}) usata nella programmazione di rete. La loro origine risale al @@ -14,9 +18,14 @@ I socket infatti sono la principale API (\textit{Application Program sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché siano state sviluppate interfacce alternative, originate dai sistemi SYSV, come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la -diffusione e la popolarità di quella dei socket (e tantomeno usabilità e +diffusione e la popolarità di quella dei socket (né tantomeno usabilità e flessibilità). +La flessibilità e la genericità dell'interfaccia inoltre ha consentito di +utilizzare i socket con i più disparati meccanismi di comunicazione, e non +solo con la suite dei protocolli TCP/IP, che sarà comunque quella di cui +tratteremo in maniera più estesa. + \section{Concetti base} \label{sec:sock_gen} @@ -61,11 +70,11 @@ tipi di socket, che vengono classificati raggruppandoli in quelli che si chiamano \textsl{domini} (\textit{domains}). La scelta di un dominio equivale in sostanza alla scelta di una famiglia di protocolli. Ciascun dominio ha un suo nome simbolico che convenzionalmente inizia con \texttt{PF\_} (da -\textit{protocol family}, altro nome con cui si indicano i domini). +\textit{Protocol Family}, altro nome con cui si indicano i domini). A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per -\texttt{AF\_} (da \textit{Address Family}, nome che useremo anche noi; le man -pages di linux si riferiscono a questi anche come \textit{name space}, nome +\texttt{AF\_} da \textit{Address Family}, nome che useremo anche noi; le man +pages di linux si riferiscono a questi anche come \textit{name space}, (nome che però il manuale della glibc riserva ai domini) e che identifica il formato degli indirizzi usati in quel dominio. @@ -92,7 +101,6 @@ riportate in \ntab. \label{tab:net_pf_names} \end{table} - La scelta di un dominio non comporta però la scelta dello stile di comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di