From: Simone Piccardi Date: Tue, 10 Apr 2001 22:44:54 +0000 (+0000) Subject: Cambiamenti e aggiunte minori. X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=87372ca8a15e3e43210e42425a232579a6d79036 Cambiamenti e aggiunte minori. --- diff --git a/network.tex b/network.tex index 80d37eb..18d4ef6 100644 --- a/network.tex +++ b/network.tex @@ -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. diff --git a/socket.tex b/socket.tex index 4cc999d..de622fc 100644 --- a/socket.tex +++ b/socket.tex @@ -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} - - -