Revisione di alcune funzioni e rilettura generale.
[gapil.git] / simpltcp.tex
index 8a6b2aed9a3a28077a8c3944748c741b36be9579..c007bb0eb79694b62f6c24df9cf96900fe7b1c6c 100644 (file)
@@ -1,3 +1,13 @@
+%% simpltcp.tex
+%%
+%% Copyright (C) 2000-2002 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 "Prefazione",
+%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
 \chapter{Un esempio completo di client/server TCP}
 \label{cha:simple_TCP_sock}
 
 \chapter{Un esempio completo di client/server TCP}
 \label{cha:simple_TCP_sock}
 
@@ -243,7 +253,7 @@ La funzione utilizza due buffer per gestire i dati inviati e letti sul socket
 (linee \texttt{\small 5--10}), i dati da inviare sulla connessione vengono
 presi dallo \file{stdin} usando la funzione \func{fgets} che legge una
 linea di testo (terminata da un \texttt{CR} e fino al massimo di
 (linee \texttt{\small 5--10}), i dati da inviare sulla connessione vengono
 presi dallo \file{stdin} usando la funzione \func{fgets} che legge una
 linea di testo (terminata da un \texttt{CR} e fino al massimo di
-\macro{MAXLINE} caratteri) e la salva sul buffer di invio, la funzione
+\const{MAXLINE} caratteri) e la salva sul buffer di invio, la funzione
 \func{SockWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo
 l'invio multiplo qualora una singola \func{write} non basti, come spiegato
 in \secref{sec:sock_io_behav}).
 \func{SockWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo
 l'invio multiplo qualora una singola \func{write} non basti, come spiegato
 in \secref{sec:sock_io_behav}).
@@ -397,7 +407,7 @@ quando affronteremo il comportamento in caso di conclusioni anomale:
 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
 del procedimento di chiusura del processo figlio nel server (si veda quanto
 esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del
 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
 del procedimento di chiusura del processo figlio nel server (si veda quanto
 esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del
-segnale \macro{SIGCHLD} al padre, ma dato che non si è installato un
+segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
 manipolatore e che l'azione predefinita per questo segnale è quella di essere
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
 otterremo che il processo figlio entrerà nello stato di zombie (si riveda
 manipolatore e che l'azione predefinita per questo segnale è quella di essere
 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
 otterremo che il processo figlio entrerà nello stato di zombie (si riveda
@@ -412,7 +422,7 @@ Poich
 spazio nella tabella dei processi e a lungo andare saturerebbero le risorse
 del kernel, occorrerà ricevere opportunamente lo stato di terminazione del
 processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando
 spazio nella tabella dei processi e a lungo andare saturerebbero le risorse
 del kernel, occorrerà ricevere opportunamente lo stato di terminazione del
 processo (si veda \secref{sec:proc_wait}), cosa che faremo utilizzando
-\macro{SIGCHLD} secondo quanto illustrato in \secref{sec:sig_sigchld}.
+\const{SIGCHLD} secondo quanto illustrato in \secref{sec:sig_sigchld}.
 
 La prima modifica al nostro server è pertanto quella di inserire la gestione
 della terminazione dei processi figli attraverso l'uso di un manipolatore.
 
 La prima modifica al nostro server è pertanto quella di inserire la gestione
 della terminazione dei processi figli attraverso l'uso di un manipolatore.