X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;ds=sidebyside;f=tcpsockadv.tex;h=c8e9ec4ace77b08e43c309aaffb01e43d0136737;hb=8e5ef936044c774fd84c348afbd4ebc30c8ff2d1;hp=7351738281d804bdd6762a143c2b2c93ced5cb26;hpb=38b9e1e53adc5b440459a6044f3a8ff133f34824;p=gapil.git diff --git a/tcpsockadv.tex b/tcpsockadv.tex index 7351738..c8e9ec4 100644 --- a/tcpsockadv.tex +++ b/tcpsockadv.tex @@ -1,4 +1,4 @@ - %% tcpsockadv.tex +%% tcpsockadv.tex %% %% Copyright (C) 2003 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free @@ -658,22 +658,87 @@ presenta un file descriptor aperto, e lo imposta (\texttt{\small 44}) come nuovo massimo, per poi tornare (\texttt{\small 44}) al ciclo principale con un \code{break}, e rieseguire \func{select}. -Se infine si sono letti dei dati (ultimo caso rimasto) si potrà invocare -(\texttt{\small 49}) \func{FullWrite} per riscriverli indietro sul socket in -questione, avendo cura di uscire con un messaggio in caso di errore -(\texttt{\small 50--53}). +Se infine si sono effettivamente letti dei dati dal socket (ultimo caso +rimasto) si potrà invocare immediatamente (\texttt{\small 49}) +\func{FullWrite} per riscriverli indietro sul socket stesso, avendo cura di +uscire con un messaggio in caso di errore (\texttt{\small 50--53}). Si noti +che nel ciclo si esegue una sola lettura, contrariamente a quanto fatto con la +precedente versione (si riveda il codice di \secref{fig:TCP_ServEcho_second}) +in cui si continuava a leggere fintanto che non si riceveva un +\textit{end-of-file}, questo perché usando l'\textit{I/O multiplexing} non si +vuole essere bloccati in lettura. L'uso di \func{select} ci permette di +trattare automaticamente anche il caso in cui la \func{read} non è stata in +grado di leggere tutti i dati presenti sul socket, dato che alla iterazione +successiva \func{select} ritornerà immediatamente segnalando l'ulteriore +disponibilità. + +Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo +\textit{Denial of Service}. Il problema è che in caso di blocco di una +qualunque delle funzioni di I/O, non avendo usato processi separati, tutto il +server si ferma e non risponde più a nessuna richiesta. Abbiamo scongiurato +questa evenienza per l'I/O in ingresso con l'uso di \func{select}, ma non vale +altrettanto per l'I/O in uscita. Il problema pertanto può sorgere qualora una +delle chiamate a \func{write} effettuate da \func{FullWrite} si blocchi. Con +il funzionamento normale questo non accade in quanto il server si limita a +scrivere quanto riceve in ingresso, ma qualora venga utilizzato un client +malevolo che esegua solo scritture e non legga mai indietro l'\textsl{eco} del +server, si potrebbe giungere alla saturazione del buffer di scrittura, ed al +conseguente blocco del server su di una \func{write}. + +Le possibili soluzioni in questo caso sono quelle di ritornare ad eseguire il +ciclo di risposta alle richieste all'interno di processi separati, utilizzare +un timeout per le operazioni di scrittura, o eseguire queste ultime in +modalità non bloccante, cocludendo le operazioni qualora non vadano a buon +fine. + + + +\subsection{I/O multiplexing con \func{poll}} +\label{sec:TCP_serv_poll} + +Finora abbiamo trattato le problematiche risolubili con l'I/O multiplexing +impiegando la funzione \func{select}; questo è quello che avviene nella +maggior parte dei casi, in quanto essa è nata sotto BSD proprio per affrontare +queste problematiche con i socket. Abbiamo però visto in +\secref{sec:file_multiplexing} come esistono altre funzioni che permettono di +affrontare lo stesso problema e come la funzione \func{poll} possa costituire +una alternativa a \func{select}, con alcuni vantaggi.\footnote{non soffrendo + delle limitazioni dovute all'uso dei \textit{file descriptor set}.} + +Ancora una volta in \secref{sec:file_poll} abbiamo trattato la funzione in +maniera generica, parlando di file descriptor, ma come per \func{select} +quando si ha a che fare con dei socket il concetto di essere \textsl{pronti} +per l'I/O deve essere specificato nei dettagli, per tener conto delle +condizioni della rete. Inoltre deve essere specificato come viene classificato +il traffico nella suddivisione fra dati normali e prioritari. In generale +pertanto: +\begin{itemize} +\item i dati trasmessi su un socket vengono considerati traffico normale, + pertanto vengono rilevati da una selezione con \const{POLLIN} o + \const{POLLRDNORM}. +\item i dati \textit{out-of-band} su un socket TCP vengono considerati + traffico prioritario e vengono rilevati da una condizione \const{POLLIN}, + \const{POLLPRI} o \const{POLLRDBAND}. +\item la chiusura di una connessione (cioè la ricezione di un segmento FIN) + viene considerato traffico normale, pertanto viene rilevato da una + condizione \const{POLLIN} o \const{POLLRDNORM}, ma una conseguente chiamata + a \func{read} restituirà 0. +\item la presenza di un errore sul socket (sia dovuta ad un segmento RST che a + timeout) viene considerata traffico normale, ma viene segnalata anche dalla + condizione \const{POLLERR}. +\item la presenza di una nuova connessione su un socket in ascolto può essere + considerata sia traffico normale che prioritario, nel caso di Linux + l'implementazione la classifica come normale. +\end{itemize} + +Come esempio dell'uso di \func{poll} proviamo allora a reimplementare il +server \textit{echo} secondo lo schema di \figref{fig:TCP_echo_multiplex} +usando \func{poll} al posto di \func{select}. In questo caso dovremo fare +qualche modifica, -\subsection{Un esempio di I/O multiplexing con \func{poll}} -\label{sec:TCP_serv_poll} -Abbiamo visto in \secref{sec:TCP_serv_select} come creare un server che -utilizzi l'I/O multiplexing attraverso l'impiego della funzione \func{select}, -ma in \secref{sec:file_multiplexing} abbiamo visto come la funzione -\func{poll} costituisca una alternativa a \func{select} con delle funzionalità -migliori, vediamo allora come reimplementare il nostro servizio usando questa -funzione. \section{Le opzioni dei socket}