Cambiamenti e aggiunte minori.
authorSimone Piccardi <piccardi@gnulinux.it>
Tue, 10 Apr 2001 22:44:54 +0000 (22:44 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Tue, 10 Apr 2001 22:44:54 +0000 (22:44 +0000)
network.tex
socket.tex

index 80d37ebad9a5bd76f3290f8f92c1969a16bd6618..18d4ef6ba0134bab9efe88d801738f2837962c91 100644 (file)
@@ -12,7 +12,6 @@ quello che sta alla base di internet, ed in particolare prenderemo in esame in
 questa introduzione i concetti più importanti da conoscere ai fini della
 programmazione.
 
-
 \section{Il modello client-server}
 \label{sec:net_cliserv}
 
@@ -116,10 +115,10 @@ int main(int argc, char *argv[])
 \end{figure}
 
 Scopo di questo esempio è fornire un primo approccio alla programmazione di
-rete, per questo motivo non ci dilungheremo nel trattare il significato dei
+rete, per questo motivo non ci dilungheremo nello spiegare il significato dei
 termini o il funzionamento delle varie funzioni utilizzate. Tutto questo sarà
 esaminato in dettaglio nel seguito, per cui qui ci limiteremo a citarli senza
-ulteriori spiegazioni.
+ulteriori dettagli.
 
 Il sorgente completo del programma (\texttt{SimpleDaytimeTCPClient.c}, che
 comprende il trattamento delle opzioni e una funzione per stampare un
@@ -297,11 +296,15 @@ parte il fatto di essere dipendente da IPv4, esso 
 un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
 scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
-attiva), occorrerebbero delle opportune modifiche.
+attiva e il terminale da cui lo si è lanciato è stato sconnesso),
+occorrerebbero delle opportune modifiche.
 
 \section{I protocolli di rete}
 \label{sec:net_protocols}
 
+Visto un primo esempio di programmazione, passiamo ora ad una introduzione più
+dettagliata del funzionamento delle reti e dei relativi protocolli.
+
 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
 ottica, alle comunicazioni via satellite; per rendere possibile la
@@ -348,11 +351,22 @@ quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
   Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
 della Difesa Americano.
 
+
+\begin{figure}[!htbp]
+  \centering
+  
+  \caption{Struttura a livelli dei protocolli OSi e TCP/IP, con la  
+    relative corrispondeze e la divisione fra kernel e user space.}
+  \label{fig:net_osi_tcpip_comp}
+\end{figure}
+
+
+
 \subsection{Il modello DoD (TCP/IP)}
 \label{sec:net_tcpip_overview}
 
 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
-\ntab); un confronto fra i due è riportato in \nfig\ dove viene evidenziata
+\ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
 anche la corrispondenza fra i rispettivi livelli (che comunque è
 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
 operativo rispetto alla divisione fra user space e kernel space spiegata in
@@ -404,6 +418,15 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
 La comunicazione fra due stazioni avviene pertanto secondo le modalità
 illustrate in \nfig. 
 
+
+\begin{figure}[!htbp]
+  \centering
+  
+  \caption{Strutturazione del flusso dei dati nella comunicazione fra due
+    applicazioni attraverso i protocolli della suite TCP/IP.}
+  \label{fig:net_tcpip_data_flux}
+\end{figure}
+
 Le singole applicazioni si scambieranno i dati secondo un loro formato
 specifico, implementando un protocollo di applicazione (esempi possono essere
 HTTP, POP, telnet, SMTP, etc). 
@@ -466,32 +489,45 @@ trattato uniformemente da tutti i nodi della rete.
 \section{Il protocollo TCP/IP}
 \label{sec:net_tpcip}
 
-Come già affermato il protocollo TCP/IP è un insieme di protocolli diversi,
+Come appena mostrato il protocollo TCP/IP è un insieme di protocolli diversi,
 che operano su 4 livelli diversi. Per gli interessi della programmazione di
 rete però sono importanti principalmente i due livelli centrali, e soprattutto
-quello di trasporto, su cui è innestata l'interfaccia fra kernel space e user
-space. 
-
-Il livello 4 infatti è normalmente gestito dal kernel, e si accede ad esso
-solo quando si vogliono fare applicazioni di sistema per il controllo della
-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.
+quello di trasporto. 
+
+La principale interfaccia di programmazione di rete, quella dei socket, è
+infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perché al
+di sopra del livello di trasporto i programmi hanno a che fare solo con
+dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
+i dettagli relativi alla comunicazione. È pertanto naturale definire una API
+su questo confine tanto più che è proprio li (come evidenziato in \pfig) che
+nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
+user space.
+
+In realtà in un sistema unix è possibile accedere anche agli altri livelli
+inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
+è indicata in \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
+usate solo quando si vogliono fare applicazioni di sistema per il controllo
+della rete a basso livello, un uso quindi molto specialistico, e che non
+rientra in quanto trattato 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.
+concentrandoci per le ragioni esposte sul livello di trasposto. All'interno di
+questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
+nella maggior parte delle applicazioni.
 
 \subsection{Il quadro generale}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
-altri membri. In \nfig\ si è riportato una figura di quadro che mostra un
-panorama sull'intera famiglia, e di come i vari protocolli vengano usati dalle
-applicazioni.
+altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
+vari prottocolli della famiglia, e delle loro relazioni reciproche e con
+alcune dalle principali applicazioni che li usano.
 
-La figura è da fare  ...
+\begin{figure}[!htbp]
+  \centering
+  
+  \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
+  \label{fig:net_tcpip_overview}
+\end{figure}
 
 I vari protocolli mostrati in figura sono i seguenti:
 
@@ -507,9 +543,9 @@ I vari protocolli mostrati in figura sono i seguenti:
   orientato alla connessione che provvede un trasporto affidabile e
   bidirezionale di un flusso di dati. I socket TCP sono esempi di
   \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
-  trasporto, come l'acknoweledgment, i timout, la ritrasmissione, etc. È usato
-  dalla maggior parte delle applicazioni. Può essere usato sia con IPv4 che
-  con IPv6.
+  trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È 
+  usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
+  che con IPv6.
 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
   connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
     socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
@@ -517,10 +553,11 @@ I vari protocolli mostrati in figura sono i seguenti:
   ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
   errori e trasporta l'informazione di controllo fra stazioni remote e
-  instradatori (\textit{router} e \textit{host}). I messaggi sono normalmente
+  instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
   generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
-  se può venire usato direttamente da alcuni programmi come \texttt{ping}. A
-  volte ci si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
+  se ICMP può venire usato direttamente da alcuni programmi come
+  \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
+  da ICMPv6.
 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
   protocollo usato per il \textit{multicasting} (vedi
   \ref{sec:xxx_multicast}), che è opzionale in IPv4.
@@ -552,7 +589,7 @@ Quando si parla di IP ci si riferisce in genere alla versione attualmente in
 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
 venne standardizzata nel 1981 dall'RFC~719.
 
-Internet protocol nasce per disaccoppiare le applicazioni della struttura
+Internet Protocol nasce per disaccoppiare le applicazioni della struttura
 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
 dei dati indipendente dal sottostante substrato di rete, che può essere
 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
@@ -584,19 +621,19 @@ grandi linee nei seguenti punti:
   supportare una gerarchia con più livelli di indirizzamento, un numero di
   nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
-  si aggiungono agli usuali \textit{unycast} e \textit{multicast}
+  si aggiunge agli usuali \textit{unycast} e \textit{multicast}
 \item la semplificazione del formato della testata, eliminando o rendendo
   opzionali alcuni dei campi di IPv4, per eliminare la necessità di
   riprocessamento della stessa da parte dei router e contenere l'aumento di
-  dimensione dovuto ai nuovi indirizzi
+  dimensione dovuto all'ampiamento degli indirizzi
 \item un supporto per le opzioni migliorato, per garantire una trasmissione
   più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
   delle opzioni, e la flessibilità necessaria per introdurne di nuove in
   futuro
-\item il supporto per delle capacità di qualità di servizio (QoS) che permetta
-  di identificare gruppi di dati per i quali si può provvedere un trattamento
-  speciale (in vista dell'uso di internet per applicazioni multimediali e/o
-  ``real-time'')
+\item il supporto per delle capacità di qualità di servizio (QoS) che
+  permettano di identificare gruppi di dati per i quali si può provvedere un
+  trattamento speciale (in vista dell'uso di internet per applicazioni
+  multimediali e/o ``real-time'')
 \end{itemize}
 
 Per maggiori dettagli riguardo al protocollo si può consultare
@@ -646,7 +683,7 @@ Nonostante gli evidenti svantaggi comportati dall'inaffidabilit
 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.
+essere tollerata, ad esempio quelle che usano il multicasting.
 
 \subsection{TCP: Transport Control Protocol)}
 \label{sec:net_tcp}
@@ -660,15 +697,16 @@ La prima differenza con UDP 
 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.
+due i due capi della comunicazione su cui poi viene quest'ultima viene
+effettuata.
 
 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
+ritrasmessi per un determinato numero di tentativi, intervallati da un
+periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
+connessione (e generato 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
@@ -710,12 +748,23 @@ effettuato per entrambe le direzioni di comunicazione.
 
 
 
+
+
+\chapter{Socket TCP elementari}
+
+Esamineremo in questo capitolo quanto necessario per capire come scrivere un
+client e un server TCP, riprendendo quanto visto in \ref{sec:net_cli_sample} e
+\ref{sec:net_cli_server}. 
+
+
+
 \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.
+operano con TCP (le varie \texttt{connect}, \texttt{accept}, \texttt{close}
+che abbiamo visto negli esempi iniziali e su cui torneremo più avatni) è
+fodamentale capire come funziona la creazione e la conclusione di una
+connessione TCP.
 
 
 
index 4cc999d34818865533ddcab50e8c2cadb0ca500f..de622fcc5794dae29c0a5746e42105c70aefeb9e 100644 (file)
@@ -1,5 +1,5 @@
-\chapter{Socket}
-\label{cha:socket}
+\chapter{Introduzione ai socket}
+\label{cha:socket_intro}
 
 Il \textit{socket} (traducibile liberamente come \textsl{manicotto}) è uno dei
 principali meccanismi di comunicazione fra programmi utilizzato in ambito unix
@@ -12,9 +12,9 @@ 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
-1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta
+Quella dei socket costituisce infatti la principale API (\textit{Application
+  Program Interface}) usata nella programmazione di rete.  La loro origine
+risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta
 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
@@ -78,6 +78,7 @@ 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.
 
+
 I domini (e i relativi nomi simbolici) sono definiti dall'header
 \textit{socket.h}. In linux sono disponibili le famiglie di protocolli
 riportate in \ntab.
@@ -130,6 +131,3 @@ glibc chiama \textit{styles}) definiti come \texttt{int} in \texttt{socket.h}:
 \end{list}
 
 
-
-
-