From: Simone Piccardi Date: Sat, 9 Jun 2001 21:08:45 +0000 (+0000) Subject: Iniziato capitolo sul server echo, modificato Makefile secondo i suggerimenti X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=091527e47fd90180e50ceee95a72340f990d999f Iniziato capitolo sul server echo, modificato Makefile secondo i suggerimenti di L. Fasolo per fargli generare meglio le figure --- diff --git a/Makefile b/Makefile index f32575b..3ce1862 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,5 @@ html: - latex2html main.tex + latex2html -local_icons main.tex dvi: latex main.tex diff --git a/elemtcp.tex b/elemtcp.tex index 50d8994..f8bc164 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -8,10 +8,6 @@ nei due esempi elementari forniti in precedenza (vedi descrizione delle principali caratteristiche del funzionamento di una connessione TCP. -Infine riscriveremo il precedente esempio elementare di server -\texttt{daytime} in una forma appena più evoluta (come server concorrente) e -con alcune caratteristiche aggiuntive che mettano in luce quanto andremo ad -illustrare. \section{Il funzionamento di una connessione TCP} \label{sec:TCPel_connession} @@ -1243,27 +1239,32 @@ quella connessione. La funzione \texttt{getpeername} si usa tutte le volte che si vuole avere l'indirizzo remoto di un socket. -Benché nell'esempio precedente si siano usati i valori di ritorno di -\texttt{accept} per ottenere l'indirizzo del client remoto, in generale questo -non è possibile. In particolare questo avviene quando il server invece di far -gestire la connessione direttamente al figlio, come nell'esempio precedente, -lancia un opportuno programma per ciascuna connessione usando \texttt{exec} -(come ad esempio fa il \textsl{super-server} \texttt{inetd} che gestisce tutta -una serie di servizi lanciando per ogni connessione l'opportuno server). +Ci si può chiedere a cosa serva questa funzione dato che dal lato client +l'indirizzo remoto è sempre noto quando si esegue la \texttt{connect} mentre +dal lato server si possono usare, come si è fatto nell'esempio precedente, i +valori di ritorno di \texttt{accept}. + +In generale però questa ultima possibilità è sempre possibile. In particolare +questo avviene quando il server invece di far gestire la connessione +direttamente a un processo figlio, come nell'esempio precedente, lancia un +opportuno programma per ciascuna connessione usando \texttt{exec} (questa ad +esempio è la modailità con cui opera il \textsl{super-server} \texttt{inetd} +che gestisce tutta una serie di servizi lanciando per ogni connessione +l'opportuno server). In questo caso benché il processo figlio abbia una immagine della memoria che è copia di quella del processo padre (e contiene quindi anche la struttura -ritornata da \texttt{accept}) all'esecuzione di \texttt{exec} viene caricata +ritornata da \texttt{accept}), all'esecuzione di \texttt{exec} viene caricata in memoria l'immagine del programma eseguito che a questo punto perde ogni -riferimento; ma il socket descriptor resta aperto. Allora se una opportuna +riferimento. Il socket descriptor però resta aperto. Allora se una opportuna convenzione è seguita per rendere noto al programma eseguito qual'è il socket connesso (\texttt{inetd} ad esempio fa sempre in modo che i file descriptor 0, -1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare +1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione \texttt{getpeername} per determinare l'indirizzo remoto del client. -Infine è da chiarire che come per \texttt{accept} il terzo parametro che è -specificato dallo standard POSIX 1003.1g come di tipo \texttt{socklen\_t *} in -realtà deve sempre corrispondere ad un \texttt{int *} come prima dello -standard perché tutte le implementazioni dei socket BSD fanno questa -assunzione. +Infine è da chiarire (si legga la man page) che come per \texttt{accept} il +terzo parametro che è specificato dallo standard POSIX 1003.1g come di tipo +\texttt{socklen\_t *} in realtà deve sempre corrispondere ad un \texttt{int *} +come prima dello standard perché tutte le implementazioni dei socket BSD fanno +questa assunzione. diff --git a/main.tex b/main.tex index 0a2977c..e2b93ad 100644 --- a/main.tex +++ b/main.tex @@ -107,6 +107,7 @@ \include{network} \include{socket} \include{elemtcp} +\include{simpltcp} \include{app_a} \include{app_b} \include{fdl} diff --git a/simpltcp.tex b/simpltcp.tex new file mode 100644 index 0000000..de49446 --- /dev/null +++ b/simpltcp.tex @@ -0,0 +1,35 @@ +\chapter{Un esempio completo di client/server TCP} +\label{cha:simple_TCP_sock} + +In questo capitolo riprenderemo le funzioni trattate nel precedente, usandole +per scrivere una prima applicazione client/server che usi i socket TCP per una +comunicazione in entrambe le direzioni. + +L'applicazione sarà una implementazione elementare, ma completa, del servizio +\texttt{echo}. Si è scelto di usare questo servizio, seguendo lo Stevens, in +quanto esso costituisce il prototipo ideale di una generica applicazione di +rete; pertanto attraverso questo esempio potremo illustrare i fondamenti con i +quali si può costruire una qualunque applicazione di rete. + +Inoltre prenderemo in esame, oltre al comportamento in condizioni normali, +anche tutti i possibili scenari particolari (errori, sconnessione della rete, +crash del client o del server durante la connessione) che possono avere luogo +durante l'impiego di una applicazione di rete. + + +\section{Il servizio \texttt{echo}} +\label{sec:TCPsimp_echo} + +Il servizio \texttt{echo} è uno dei servizi standard solitamente provvisti +direttamente dal superserver \texttt{inetd}, definito dall'RFC~862. Come dice +il nome il servizio deve semplicemente rimandare indietro i dati che gli +vengono inviati; l'RFC specifica che per il TCP una volta stabilita la +connessione ogni dato in ingresso deve essere rimandato in uscita, fintanto +che il chiamante non ha chiude la connessione; il servizio opera sulla porta +TCP numero 7. + +Nel nostro caso l'esempio sarà strutturato scrivendo un client che legge una +linea dallo standard input e la scrive sul server, il server leggerà una linea +dalla connessione e la riscriverà all'indietro; sarà compito del client +leggere la risposta del server e stamparla sullo standard output. +