%% tcpsock.tex
%%
-%% Copyright (C) 2000-2018 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2019 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 "Un preambolo",
in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
-\itindex{Maximum~Segment~Lifetime}
+\itindbeg{Maximum~Segment~Lifetime~(MSL)}
Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
esegue la chiusura attiva resta prima di passare alla chiusura definitiva
TTL (da \textit{time to live}) non è propriamente un limite sul tempo, sulla
sua base si può stimare che un pacchetto IP non possa restare nella rete per
più un certo numero di secondi, che costituisce la MSL.
+\itindend{Maximum~Segment~Lifetime~(MSL)}
Ogni realizzazione del TCP deve scegliere un valore per la MSL;
l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
lo stesso vale per \var{conn\_fd} dopo il ritorno di \func{accept}, ma dopo la
\func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
-entrambi i socket si trovano con due referenze. Questo fa si che quando il
+entrambi i socket si trovano con due referenze. Questo fa sì che quando il
padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
Quando si concluderà l'invio di dati mandando un \textit{end-of-file} sullo
\textit{standard input} si avrà il ritorno di \func{fgets} con un puntatore
-nullo (si riveda quanto spiegato in sez.~\ref{sec:file_line_io}) e la
+nullo (si riveda quanto spiegato in sez.~\ref{sec:file_unformatted_io}) e la
conseguente uscita dal ciclo; al che la subroutine ritorna ed il nostro
programma client termina.
Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
niente fintanto che non si preme il tasto di a capo (si ricordi quanto detto
-in sez.~\ref{sec:file_line_io} a proposito dell'I/O su terminale). Solo
-allora \func{fgets} ritornerà ed il client scriverà quanto immesso dal
+in sez.~\ref{sec:file_unformatted_io} a proposito dell'I/O su terminale).
+Solo allora \func{fgets} ritornerà ed il client scriverà quanto immesso dal
terminale sul socket, per poi passare a rileggere quanto gli viene inviato
all'indietro dal server, che a sua volta sarà inviato sullo \textit{standard
output}, che nel caso ne provoca l'immediata stampa a video.
errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
\end{itemize*}
-Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
+Infine c'è una sola condizione che fa sì che \func{select} ritorni segnalando
che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
condizione di eccezione pendente, e cioè la ricezione sul socket di
\textsl{dati urgenti} (o \textit{out-of-band}), una caratteristica specifica
quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
dei programmi, se infatti si sa che una applicazione non è in grado di fare
niente fintanto che non può ricevere o inviare una certa quantità di dati, si
-possono utilizzare questi valori per far si che \func{select} ritorni solo
+possono utilizzare questi valori per far sì che \func{select} ritorni solo
quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
controllo è utile di norma solo per la lettura, in quanto in genere le
operazioni di scrittura sono già controllate dall'applicazione, che sa
projects / gapil.git / blobdiff