X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=othersock.tex;h=3aa2bb905ba5448ba0fe30965e0d242d369f1382;hp=3944e5d437db4eaa44410aec87e07ff6842f9a5d;hb=6f8e0ca42d3d0b97b5e5747798a1eaffb44e8521;hpb=8bfe80f7fe2470bf0a26d656b281ea44c69d8fe5 diff --git a/othersock.tex b/othersock.tex index 3944e5d..3aa2bb9 100644 --- a/othersock.tex +++ b/othersock.tex @@ -1,9 +1,9 @@ %% othersock.tex %% -%% Copyright (C) 2004 Simone Piccardi. Permission is granted to +%% Copyright (C) 2004-2005 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the -%% Free Software Foundation; with the Invariant Sections being "Prefazione", +%% Free Software Foundation; with the Invariant Sections being "Un preambolo", %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the %% license is included in the section entitled "GNU Free Documentation %% License". @@ -54,10 +54,11 @@ utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}. Questa differenza comporta ovviamente che anche le modalità con cui si usano i socket UDP sono completamente diverse rispetto ai socket TCP, ed in particolare non esistendo il concetto di connessione non esiste il meccanismo -del \textit{three way handshake} né quello degli stati del protocollo. In -realtà tutto quello che avviene nella comunicazione attraverso dei socket UDP -è la trasmissione di un pacchetto da un client ad un server o viceversa, -secondo lo schema illustrato in fig.~\ref{fig:UDP_packet-exchange}. +del \itindex{three~way~handshake}\textit{three way handshake} né quello degli +stati del protocollo. In realtà tutto quello che avviene nella comunicazione +attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un +server o viceversa, secondo lo schema illustrato in +fig.~\ref{fig:UDP_packet-exchange}. \begin{figure}[htb] \centering @@ -130,11 +131,11 @@ la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. 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 + \texttt{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva + usato un \texttt{unsigned int}; l'argomento \param{len} era \texttt{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}.} è: + l'argomento \param{tolen} era \texttt{int} nei vari BSD4.* nelle \acr{libc4} + e nelle \acr{libc5}.} è: \begin{functions} \headdecl{sys/types.h} \headdecl{sys/socket.h} @@ -219,9 +220,9 @@ La seconda funzione utilizzata nella comunicazione fra socket UDP \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le - \acr{libc5} usano un \type{int} come valore di ritorno; per gli argomenti + \acr{libc5} usano un \texttt{int} come valore di ritorno; per gli argomenti \param{flags} e \param{len} vale quanto detto a proposito di \func{sendto}; - infine l'argomento \param{fromlen} è \type{int} per i vari BSD4.*, le + infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le \acr{libc4} e le \acr{libc5}.} è: \begin{functions} \headdecl{sys/types.h} @@ -264,9 +265,10 @@ 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 la struttura contenente quest'ultimo e la relativa lunghezza saranno scritti (si noti che -\param{fromlen} è un valore intero ottenuto come \textit{value return - argument}). Se non si è interessati a questa informazione, entrambi gli -argomenti devono essere inizializzati al valore \const{NULL}. +\param{fromlen} è un valore intero ottenuto come +\itindex{value~result~argument}\textit{value result argument}). Se non si è +interessati a questa informazione, entrambi gli argomenti devono essere +inizializzati al valore \const{NULL}. Una differenza fondamentale del comportamento di queste funzioni rispetto alle usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in @@ -321,9 +323,9 @@ Il passo successivo (\texttt{\small 13--21}) struttura degli indirizzi; prima (\texttt{\small 14}) si cancella completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine -(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare dal -parametro passato a riga di comando, convertendolo con \func{inet\_pton}. Si -noti come questa sezione sia identica a quella del client TCP di +(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare +dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}. +Si noti come questa sezione sia identica a quella del client TCP di fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso di UDP al posto di TCP è stata effettuata quando si è creato il socket. @@ -693,7 +695,7 @@ illustrate in fig.~\ref{fig:UDP_echo_conn_cli}. Ed in questo caso rispetto alla precedente versione, il solo cambiamento è l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della chiamata alla funzione di gestione del protocollo, che a sua volta è stata -modificata eliminando l'indirizzo passato come parametro e sostituendo le +modificata eliminando l'indirizzo passato come argomento e sostituendo le chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e \func{write} come illustrato dal nuovo codice riportato in fig.~\ref{fig:UDP_echo_conn_echo_client}. @@ -746,13 +748,19 @@ l'interfaccia di programmazione che serve ad utilizzarli resta sempre quella dei socket. +\section{I socket \textit{raw}} +\label{sec:socket_raw} + +Tratteremo in questa sezione i cosiddetti \textit{raw socket}, con i quali si +possono \textsl{forgiare} direttamente i pacchetti a tutti i livelli dello +stack dei protocolli. + \section{Altri socket} \label{sec:socket_other} Tratteremo in questa sezione gli altri tipi particolari di socket supportati -da Linux, come i \textit{raw socket}, con i quali si possono \textsl{forgiare} -direttamente i pacchetti a tutti i livelli dello stack dei protocolli, o i +da Linux, come quelli relativi a particolare protocolli di trasmissione ed i socket \textit{netlink} che definiscono una interfaccia di comunicazione con il kernel.