tcpsockadv.tex

   1  %% tcpsockadv.tex
   2 %%
   3 %% Copyright (C) 2003 Simone Piccardi.  Permission is granted to
   4 %% copy, distribute and/or modify this document under the terms of the GNU Free
   5 %% Documentation License, Version 1.1 or any later version published by the
   6 %% Free Software Foundation; with the Invariant Sections being "Prefazione",
   7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
   8 %% license is included in the section entitled "GNU Free Documentation
   9 %% License".
  10 %%
  11 \chapter{Socket TCP avanzati}
  12 \label{cha:TCP_advanced}
  13
  14 Esamineremo in questo capitolo le funzionalità più evolute della gestione dei
  15 socket TCP.
  16
  17
  18
  19 \section{Socket multiplexing}
  20 \label{sec:TCP_sock_multiplexing}
  21
  22 Affronteremo in questa sezione l'utilizzo dell'I/O multiplexing, affrontato in
  23 \secref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già in
  24 \ref{sec:TCP_server_crash} era emerso il problema relativo al client del
  25 servizio echo che non era in grado di accorgersi della terminazione precoce
  26 del server essendo bloccato nella lettura dei dati immessi da tastiera.
  27
  28 Abbiamo visto in \secref{sec:file_multiplexing} quali sono le funzionalità del
  29 sistema che ci permettono di tenere sotto controllo più file descriptor in
  30 contemporanea; in quella occasione non abbiamo fatto esempi, in quanto quando
  31 si tratta con file normali questa tipologia di I/O non viene usata, è invece
  32 un caso tipico delle applicazioni di rete quello di dover gestire varie
  33 connessioni da cui possono arrivare dati comuni in maniera asincrona, per cui
  34 riprenderemo l'argomento in questa sezione.
  35
  36
  37
  38 \subsection{La funzione \func{select} con i socket.}
  39 \label{sec:TCP_sock_select}
  40
  41
  42
  43
  44 Iniziamo con la prima delle funzioni usate per l'I/O multiplexing,
  45 \func{select}, il suo funzionamento è già stato descritto in dettaglio in
  46 \secref{sec:file_multiplexing}; e sappiamo che la funzione ritorna quando uno
  47 o più dei file descriptor messi sotto controllo è pronto per la relativa
  48 operazione.
  49
  50 In quell'occasione non abbiamo però definito cosa si intende per pronto,
  51 infatti se per dei normali file, o anche per delle pipe, la condizione di
  52 essere pronti per la lettura o la scrittura è ovvia, lo è un po' meno di meno
  53 nel caso dei socket, visto che intervengono tutte le possibili condizioni
  54 dovute alla rete. Occorre allora specificare quali sono le condizioni in cui
  55 un socket risulta \textsl{pronto}.
  56
  57
  58
  59
  60
  61 \section{Le opzioni dei socket}
  62 \label{sec:TCP_sock_options}
  63
  64 Dato che la maggior parte delle opzioni dei socket sono relative ai socket
  65 TCP, ed hanno poi significato analogo quando usate con altri socket,
  66 tratteremo qui l'argomento in generale.
  67
  68
  69
  70 \section{I dati \textit{out-of-band}}
  71 \label{sec:TCP_outofband}
  72
  73 Una caratteristica speciale dei socket TCP è quella della presenza dei
  74 cosiddetti dati \textit{out-of-band}
  75
  76
  77
  78 \subsection{La funzione \func{shutdown}}
  79 \label{sec:TCP_shutdown}
  80
  81 Come spiegato in \secref{sec:TCP_conn_term} il procedimento di chiusura di un
  82 socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
  83 pertanto del tutto normale dal punto di vista del protocollo che uno dei due
  84 capi chiuda la connessione, quando l'altro capo la lascia
  85 aperta.\footnote{abbiamo incontrato questa situazione nei vari scenari critici
  86   di \secref{sec:TCP_echo_critical}.}
  87
  88 È pertanto possibile avere una situazione in cui un capo della connessione non
  89 avendo più nulla da scrivere, possa chiudere il socket, segnalando così
  90 l'avvenuta terminazione della trasmissione (l'altro capo riceverà infatti un
  91 end-of-file in lettura) mentre dall'altra parte si potrà proseguire la
  92 trasmissione dei dati scrivendo sul socket che da quel lato è ancora aperto.
  93 Questa è quella situazione in cui si dice che il socket è \textit{half
  94   closed}.
  95
  96 Il problema che si pone è che se la chiusura del socket è effettuata con la
  97 funzione \func{close}, come spiegato in \secref{sec:TCP_func_close}, si perde
  98 ogni possibilità di poter rileggere quanto l'altro capo può continuare a
  99 scrivere. Per poter permettere allora
 100
 101
 102
 103
 104 %%% Local Variables:
 105 %%% mode: latex
 106 %%% TeX-master: "gapil"
 107 %%% End: