From: Simone Piccardi Date: Sun, 14 Mar 2004 22:55:12 +0000 (+0000) Subject: Usato geometry per le dimensioni della pagina, e completati i commenti X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=b48ed69667f28044d3adb045e68001830fdeba06;p=gapil.git Usato geometry per le dimensioni della pagina, e completati i commenti riguardo revcfrom e sendto --- diff --git a/gapil.tex b/gapil.tex index dde18bf..1d15abe 100644 --- a/gapil.tex +++ b/gapil.tex @@ -42,6 +42,7 @@ \usepackage{multirow} %\usepackage{footnote} %\usepackage{mdwtab} +\usepackage{geometry} \def\tild{\char'176} @@ -49,11 +50,14 @@ % % Setting page layout % -\oddsidemargin=0.5cm -\evensidemargin=-0.5cm -\textwidth=16cm -\textheight=24.2cm -\topmargin=-1.cm +%\oddsidemargin=0.5cm +%\evensidemargin=-0.5cm +%\textwidth=16cm +%\textheight=24.2cm +%\topmargin=-1.cm +\geometry{textheight=24.2cm,textwidth=16cm} + + %\setcaptionmargin{2cm} %\renewcommand{\chaptername}{Capitolo} %\renewcommand{\contentsname}{Indice} diff --git a/othersock.tex b/othersock.tex index c5195df..5554e75 100644 --- a/othersock.tex +++ b/othersock.tex @@ -8,19 +8,20 @@ %% license is included in the section entitled "GNU Free Documentation %% License". %% -\chapter{Gli altri socket più comuni} +\chapter{Gli altri tipi di socket} \label{cha:other_socket} Dopo aver trattato in \capref{cha:TCP_socket} i socket TCP, che costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in questo -capitolo gli altri tipi di socket, +capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket deiit +\textit{Unix domain} già incontrati in \secref{sec:ipc_socketpair}. \section{I socket UDP} \label{sec:UDP_socket} Dopo i socket TCP i socket più utilizzati nella programmazione di rete sono i -socket UDP; protocolli diffusi come NFS o il DNS usano principalmente questo +socket UDP: protocolli diffusi come NFS o il DNS usano principalmente questo tipo di socket. Tratteremo in questa sezione le loro caratteristiche principali e le modalità per il loro utilizzo. @@ -102,8 +103,8 @@ porta 67). Si noti però come in questo caso la colonna che indica lo stato sia vuota. I socket UDP infatti non hanno uno stato. Inoltre anche in presenza di traffico -non si avranno indicazioni delle connessioni attive, proprio perché non esiste -niente di simile per i socket UDP, il kernel si limita infatti a ricevere i +non si avranno indicazioni delle connessioni attive, proprio perché questo +concetto non esiste per i socket UDP, il kernel si limita infatti a ricevere i pacchetti ed inviarli al processo in ascolto sulla porta cui essi sono destinati, oppure a scartarli inviando un messaggio \textit{ICMP port unreachable} qualora non vi sia nessun processo in ascolto. @@ -113,8 +114,8 @@ destinati, oppure a scartarli inviando un messaggio \textit{ICMP port \label{sec:UDP_sendto_recvfrom} Come accennato in \secref{sec:UDP_characteristics} le due funzioni principali -usate per la trasmissione di dati attraverso i socket UDP, sono \func{sendto} -e \func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che +usate per la trasmissione di dati attraverso i socket UDP sono \func{sendto} e +\func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che non esistendo con UDP il concetto di connessione, non si ha neanche a disposizione un \textsl{socket connesso} su cui sia possibile usare direttamente \func{read} e \func{write} avendo già stabilito (grazie alla @@ -123,16 +124,17 @@ sorgente e destinazione dei dati. Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due funzioni, che sono comunque usabili in generale per la trasmissione di dati -attraverso qualunque tipo di socket, dato che esse hanno la caratteristica di -provvedere tre argomenti aggiuntivi che consentono di specificare destinazione -o origine dei dati trasmessi. La prima delle due funzioni è \funcd{sendto} ed -il suo prototipo\footnote{il prototipo illustrato è quello utilizzato dalle - \acr{glibc}, che seguono le \textit{Single Unix Specification}, l'argomento - \param{flags} era di tipo \type{int} nei vari BSD4.*, mentre nelle - \acr{libc4} e \acr{libc5} veniva usato un \type{unsigned int}; l'argomento - \param{len} era \type{int} nei vari BSD4.* e nelle \acr{libc4}, ma - \type{size\_t} nelle \acr{libc5}; infine l'argomento \param{tolen} era - \type{int} nei vari BSD4.* nelle \acr{libc4} e nelle \acr{libc5}.} è: +attraverso qualunque tipo di socket. Esse hanno la caratteristica di prevedere +tre argomenti aggiuntivi attraveso i quali è possibile specificare la +destinazione o l'origine dei dati trasmessi. La prima di queste funzioni è +\funcd{sendto} ed il suo prototipo\footnote{il prototipo illustrato è quello + utilizzato dalle \acr{glibc}, che seguono le \textit{Single Unix + Specification}, l'argomento \param{flags} era di tipo \type{int} nei vari + BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva usato un + \type{unsigned int}; l'argomento \param{len} era \type{int} nei vari BSD4.* + e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5}; infine l'argomento + \param{tolen} era \type{int} nei vari BSD4.* nelle \acr{libc4} e nelle + \acr{libc5}.} è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/socket.h} @@ -187,8 +189,8 @@ il messaggio all'interno di un unico pacchetto essa fallisce con l'errore di I due argomenti \param{to} e \param{tolen} servono a specificare la destinazione del messaggio da inviare, e prendono l'indirizzo di quest'ultima, nella stessa forma in cui lo si specificherebbe per \func{connect}: \param{to} -deve cioè contere l'indirizzo IP e la porta di destinazione cui si vogliono -inviare i dati e \param{tolen} la relativa dimensione. +deve cioè contenere l'indirizzo IP e la porta di destinazione cui si vogliono +inviare i dati e \param{tolen} la relativa dimensione. Se il socket è di un tipo che prevede le connessioni, questo deve essere già connesso prima di eseguire la funzione (altrimenti si avrà un errore di @@ -242,11 +244,39 @@ Come per \func{sendto} i primi tre argomenti sono identici agli analoghi di \func{read}: dal socket vengono letti \param{len} byte che vengono salvati nel buffer \param{buf}. A seconda del tipo di socket (se di tipo \textit{datagram} o \textit{stream}) inoltre i byte in eccesso che non sono stati letti possono -rispettivamente andare persi o restare disponibili per una lettura -successiva. Se non sono disponibili dati la funzione si blocca, a meno di non -aver aperto il socket in modalità non bloccante, nel qual caso si avrà il -solito errore di \errcode{EAGAIN}. - +rispettivamente andare persi o restare disponibili per una lettura successiva. +Se non sono disponibili dati la funzione si blocca, a meno di non aver aperto +il socket in modalità non bloccante, nel qual caso si avrà il solito errore di +\errcode{EAGAIN}. Qualora \param{len} ecceda la dimensione del pacchetto la +funzione legge comunque i dati disponibili, ed il suo valore di ritorno è +comunque il numero di byte letti. + +I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere +l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere +opportunamente inizializzati con i puntatori alle variabili dove quest'ultimo +e la sua lunghezza saranno memorizzati (si noti che \param{fromlen} è un +valore intero ottenuto come \textit{value return argoment}). Se non si è +interessati a questa informazione, entrambi gli argomenti devono essere +inizializzati al valore \const{NULL}. + +Un'altra differenza fondamentale di queste funzioni rispetto alle usuali +\func{read} e \func{write} che abbiamo usato con i socket TCP è che in questo +caso è perfettamente legale inviare con \func{sendto} un pacchetto vuoto (che +nel caso conterrà solo le intestazioni di IP e di UDP), scrivendo 0 byte. Allo +stesso è possibile ricevere con \func{recvfrom} un valore di ritorno di 0 +byte, senza che questo possa configurarsi come una chiusura della +connessione\footnote{dato che la connessione non esiste, non ha senso parlare + di chiusura della connessione, pertanto con i socket UDP non è necessario + usare \func{close} per terminare la cominicazione.} o come una cessazione +delle comunicazioni. + + +\subsection{Un client elementare} +\label{sec:UDP_simple_server} + +Vediamo allora come implementare un primo server elementare su UDP; ricalcando +quanto fatto nel caso dei socket TCP prenderemo come primo esempio l'uso del +servizio \textit{time}, utilizzanto questa volta UDP.