Scritto qualcosa sugli errori

[gapil.git] / simpltcp.tex

diff --git a/simpltcp.tex b/simpltcp.tex
index 38df63e18b241f3dc0f99d3cabba23a58346f41f..3c10daae8d1d1265a94f6a5947ad1d8b94fc9659 100644 (file)
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -309,7 +309,7 @@ mentre per quanto riguarda l'esecuzione dei programmi avremo che:
 \begin{itemize}
 \item il client chiama la funzione \texttt{ClientEcho} che si blocca sulla
   \texttt{fgets} dato che non si è ancora scritto nulla sul terminale.
 \begin{itemize}
 \item il client chiama la funzione \texttt{ClientEcho} che si blocca sulla
   \texttt{fgets} dato che non si è ancora scritto nulla sul terminale.

-\item il server eseguirà una \texttt{fork} facendo chiamare al processo figlo
+\item il server eseguirà una \texttt{fork} facendo chiamare al processo figlio

   la funzione \texttt{ServEcho}, quest'ultima si bloccherà sulla \texttt{read}
   dal socket sul quale ancora non sono presenti dati.
 \item il processo padre del server chiamerà di nuovo \texttt{accept}
   la funzione \texttt{ServEcho}, quest'ultima si bloccherà sulla \texttt{read}
   dal socket sul quale ancora non sono presenti dati.
 \item il processo padre del server chiamerà di nuovo \texttt{accept}


@@ -364,10 +364,10 @@ terminazione normale della connessione, che ci servir
 casi seguenti:
 
 \begin{enumerate}
 casi seguenti:
 
 \begin{enumerate}

-\item Inviando un carattere di EOF da terminale la \texttt{fgets} ritorna
+\item inviando un carattere di EOF da terminale la \texttt{fgets} ritorna

   restituendo un puntatore nullo che causa l'uscita dal ciclo di
   \texttt{while}, così la \texttt{ClientEcho} ritorna.
   restituendo un puntatore nullo che causa l'uscita dal ciclo di
   \texttt{while}, così la \texttt{ClientEcho} ritorna.

-\item Al ritorno di \texttt{ClientEcho} ritorna anche la funzione
+\item al ritorno di \texttt{ClientEcho} ritorna anche la funzione

   \texttt{main}, e come parte del processo terminazione tutti i file
   descriptor vengono chiusi (si ricordi quanto visto in
   \secref{sec:proc_term_conclusion}), il che causa la chiusura del socket di
   \texttt{main}, e come parte del processo terminazione tutti i file
   descriptor vengono chiusi (si ricordi quanto visto in
   \secref{sec:proc_term_conclusion}), il che causa la chiusura del socket di


@@ -375,11 +375,11 @@ casi seguenti:
   risponderà con un ACK.  A questo punto il client verrà a trovarsi nello
   stato \texttt{FIN\_WAIT\_2} ed il server nello stato \texttt{CLOSE\_WAIT}
   (si riveda quanto spiegato in \secref{sec:TCPel_conn_term}).
   risponderà con un ACK.  A questo punto il client verrà a trovarsi nello
   stato \texttt{FIN\_WAIT\_2} ed il server nello stato \texttt{CLOSE\_WAIT}
   (si riveda quanto spiegato in \secref{sec:TCPel_conn_term}).

-\item Quando il server riceve il FIN la la \texttt{read} del processo figlio
+\item quando il server riceve il FIN la la \texttt{read} del processo figlio

   che gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
   ciclo di \texttt{while} e il ritorno di \texttt{ServEcho}, a questo punto il
   processo figlio termina chiamando \texttt{exit}.
   che gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
   ciclo di \texttt{while} e il ritorno di \texttt{ServEcho}, a questo punto il
   processo figlio termina chiamando \texttt{exit}.

-\item All'uscita del figlio tutti i file descriptor vengono chiusi, la
+\item all'uscita del figlio tutti i file descriptor vengono chiusi, la

   chiusura del socket connesso fa sì che venga effettuata la sequenza finale
   di chiusura della connessione, viene emesso un FIN dal server che riceverà
   un ACK dal client, a questo punto la connessione è conclusa e il client
   chiusura del socket connesso fa sì che venga effettuata la sequenza finale
   di chiusura della connessione, viene emesso un FIN dal server che riceverà
   un ACK dal client, a questo punto la connessione è conclusa e il client