From 21c0479726e1e1554f5ed48c29e412637b695e74 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 11 Nov 2001 16:27:38 +0000 Subject: [PATCH] Agginte altre figure sulla condivisione dei file e scritte read e write --- fileunix.tex | 238 +++++++++++++++++++++++++++++++++++++++++--- img/filedup.dia | Bin 0 -> 3049 bytes img/filemultacc.dia | Bin 0 -> 3978 bytes img/fileshar.dia | Bin 0 -> 3852 bytes simpltcp.tex | 6 +- socket.tex | 10 +- 6 files changed, 233 insertions(+), 21 deletions(-) create mode 100644 img/filedup.dia create mode 100644 img/filemultacc.dia create mode 100644 img/fileshar.dia diff --git a/fileunix.tex b/fileunix.tex index bc94a0e..c2412e8 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -80,7 +80,7 @@ strutture di dati sulla quale essa \centering \includegraphics[width=14cm]{img/procfile.eps} \caption{Schema della architettura dell'accesso ai file attraverso - l'interfaccia dei \textit{file descroptor}} + l'interfaccia dei \textit{file descriptor}} \label{fig:file_proc_file} \end{figure} Ritorneremo su questo schema più volte, dato che esso è fondamentale per @@ -476,9 +476,7 @@ causano un errore ma restituiscono un valore indefinito. Per leggere da un file precedentemente aperto, si può la funzione \func{read}, il cui prototipo è: -\begin{prototype} - \headdecl{unistd.h} - \funcdecl{ssize\_t read(int fd, void * buf, size\_t count)} +\begin{prototype}{unistd.h}{ssize\_t read(int fd, void * buf, size\_t count)} La funzione cerca di leggere \var{count} bytes dal file \var{fd} al buffer \var{buf}. @@ -487,41 +485,255 @@ il cui prototipo caso di errore, nel qual caso \var{errno} viene settata ad uno dei valori: \begin{errlist} \item \macro{EINTR} la funzione è stata interrotta da un segnale prima di - aver letto quasiasi dato. + aver potuto leggere quasiasi dato. \item \macro{EAGAIN} la funzione non aveva nessun dato da restituire e si era aperto il file in modalità \macro{O\_NONBLOCK}. \end{errlist} ed inoltre \macro{EBADF}, \macro{EIO}, \macro{EISDIR}, \macro{EBADF}, - \macro{EINVAL} e \macro{EFAULT}. + \macro{EINVAL} e \macro{EFAULT} ed eventuali altri errori dipendenti dalla + natura dell'oggetto connesso a \var{fd}. +\end{prototype} + +La funzione tenta di leggere \var{count} byte a partire dalla posizione +corrente nel file; dopo la lettura la posizione è spostata automaticamente in +avanti del numero di bytes letti. Se \var{count} è zero la funzione +restituisce zero senza nessun altro risultato. + +Si deve sempre tener presente che non è detto che la funzione \func{read} +restituisca il numero di byte richiesto, ci sono infatti varie ragioni per cui +la funzione può restituire un numero di byte inferiore. Questo è un +comportamento normale e non un errore, che però bisogna sempre tenere +presente. + +La prima e più ovvia di queste ragioni è che si è chiesto di leggere più bytes +di quanto il file ne contenga. In questo caso il file viene letto fino alla +sua fine, e la funzione ritorna regolarmente il numero di byte letti +effettivamente. Se ripetessimo la lettura \func{read} restituirebbe uno zero. +La condizione raggiungimento della fine del file non è un errore, e viene +segnalata appunto da un valore di ritorno di \func{read} nullo, ripetere la +lettura non avrebbe nessun effetto se non quello di continuare a ricevere zero +come valore di ritorno. + +Con i \textsl{file regolari} questa è l'unica situazione in cui si può avere +un numero di byte letti inferiore a quello richiesto, ma la situazione è +invece normale quando si legge da un terminale, o su una pipe. In tal caso +infatti, se non ci sono dati in ingresso, la \func{read} si blocca e ritorna +solo quando ne arrivano; se il numero di byte richiesti eccede quelli +disponibili la funzione ritorna comunque, ma con un numero di byte inferiore. + +Lo stesso comportamento avviene caso di lettura dalla rete (cioè su un socket, +come vedremo in \secref{sec:sock_io_behav}), o per certi dispositivi come le +unità a nastro che restituiscono un singolo blocco di dati alla volta. + +In realtà anche le due condizioni segnalate dagli errori \func{EINTR} e +\func{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è +bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in +tal caso l'azione da prendere è quella di rieseguire la funzione. Torneremo +sull'argomento in \secref{sec:signal_xxx}. + +La seconda si verifica quando il file è in modalità non bloccante e non ci +sono dati in ingresso: la funzione allora ritorna immediatamente con un errore +\macro{EAGAIN}\footnote{sotto BSD questo per questo errore viene usata la + costante \macro{EWOULDBLOCK}, in GNU/Linux questa è sinonima di + \macro{EAGAIN}.} indicando che occorrerà provare a ripetere la lettura. + + +Lo standard Unix98\footnote{questa funzione, e l'analoga \func{pwrite} sono + state aggiunte nel kernel 2.1.60, il supporto nelle \acr{glibc}, compresa + l'emulazione per i vecchi kernel che non hanno la system call, è stato + aggiutno con la versione 2.1} (vedi \secref{sec:intro_opengroup}) prevede la +definizione di un'altra funzione di lettura, \func{pread}, che diventa +accessibile con la definizione: +\begin{verbatim} + #define _XOPEN_SOURCE 500 +\end{verbatim} +il prototipo di questa funzione è: +\begin{prototype}{unistd.h} +{ssize\_t pread(int fd, void * buf, size\_t count, off\_t offset)} + +La funzione cerca di leggere \var{count} bytes dal file \var{fd}, a partire +dalla posizione \var{offset}, nel buffer \var{buf}. + +La funzione ritorna il numero di byte letti in caso di successo e -1 in caso +di errore, nel qual caso \var{errno} viene settata secondo i valori già visti +per \func{read} e \func{lseek}. \end{prototype} +Questa funzione serve quando si vogliono leggere dati dal file senza +modificarne la posizione corrente. È equivalente alla esecuzione di una +\func{read} e una \func{lseek}, ma dato che la posizione sul file può essere +condivisa fra vari processi (vedi \secref{sec:file_sharing}), essa permette di +eseguire l'operazione atomicamente. Il valore di \var{offset} fa riferimento +all'inizio del file. + \subsection{La funzione \func{write}} \label{sec:file_write} +Per scrivere su un file si usa la funzione \func{write}, il cui prototipo è: +\begin{prototype}{unistd.h}{ssize\_t write(int fd, void * buf, size\_t count)} + + La funzione scrive \var{count} bytes dal buffer \var{buf} sul file \var{fd}. + + La funzione ritorna il numero di byte scritti in caso di successo e -1 in + caso di errore, nel qual caso \var{errno} viene settata ad uno dei valori: + \begin{errlist} + \item \macro{EINVAL} \var{fd} è connesso ad un oggetto che non consente la + scrittura. + \item \macro{EFBIG} si è cercato di scrivere oltre la dimensione massima + consentita dal filesystem o il limite per le dimensioni dei file del + processo o su una posizione oltre il massimo consentito. + \item \macro{EPIPE} \var{fd} è connesso ad una pipe il cui altro capo è + chiuso in lettura; in questo caso viene anche generato il segnale + \macro{SIGPIPE}, se questo viene gestito (o bloccato o ignorato) la + funzione ritorna questo errore. + \item \macro{EINTR} la funzione è stata interrotta da un segnale prima di + aver potuto scerivere quasiasi dato. + \item \macro{EAGAIN} la funzione non aveva nessun dato da restituire e si + era aperto il file in modalità \macro{O\_NONBLOCK}. + \end{errlist} + ed inoltre \macro{EBADF}, \macro{EIO}, \macro{EISDIR}, \macro{EBADF}, + \macro{ENOSPC}, \macro{EINVAL} e \macro{EFAULT} ed eventuali altri errori + dipendenti dalla natura dell'oggetto connesso a \var{fd}. +\end{prototype} + +Come nel caso di \func{read} la funzione tenta di scrivere \var{count} byte a +partire dalla posizione corrente nel file e sposta automaticamente la +posizione in avanti del numero di bytes scritti. Se il file è aperto in +modalità \macro{O\_APPEND} i dati vengono sempre scritti alla fine del file. +Lo standard POSIX richiede che i dati scritti siano immediatamente disponibili +ad una \func{read} chiamata dopo che la \func{write} che li ha scritti è +ritornata; ma dati i meccanismi di caching non è detto che tutti i filesystem +supportino questa capacità. + +Se \var{count} è zero la funzione restituisce zero senza fare nient'altro. Per +i file ordinari il numero di bytes scritti è sempre uguale a quello indicato +da \var{count}, a meno di un errore. Negli altri casi si ha lo stesso +comportamento di \func{read}. + +Anche per \func{write} lo standard Unix98 definisce una analoga per scrivere +alla posizione indicata senza modificare la posizione corrente nel file, il +suo prototipo è: +\begin{prototype}{unistd.h} +{ssize\_t pwrite(int fd, void * buf, size\_t count, off\_t offset)} + +La funzione cerca di scrivere sul file \var{fd}, a partire dalla posizione +\var{offset}, \var{count} bytes dal buffer \var{buf}. + +La funzione ritorna il numero di byte letti in caso di successo e -1 in caso +di errore, nel qual caso \var{errno} viene settata secondo i valori già visti +per \func{write} e \func{lseek}. +\end{prototype} -\section{Funzioni avanzate} + + +\section{Caratteristiche avanzate} \label{sec:file_adv_func} +In questa sezione approfondireme alcune delle caratteristiche più sottili +della gestione file in un sistema unix-like, esaminando in dettaglio il +comportamento delle funzioni base, inoltre tratteremo alcune funzioni che +permettono di eseguire operazioni avanzate con i file. + \subsection{La condivisione dei files} \label{sec:file_sharing} -Si noti che i flag di stato del file, quelli settati dal parametro \var{flag} -di \func{open}, essendo tenuti nella vode sulla file table, vengono condivisi, -ai file sono però associati anche altri flag, (tenuti invece nella struttura -\var{file\_struct} interna alla process table) che sono unici per ciascun file -descriptor, e sono pertanto detti \textit{file descriptor flags} (l'unico -usato al momento è \macro{FD\_CLOEXEC}). +In \secref{sec:file_fd} abbiamo descritto brevemente l'architettura +dell'interfaccia coi file da parte di un processo, mostrando in +\figref{fig:file_proc_file} le principali strutture usate dal kernel; +esamineremo ora in dettaglio le conseguenze che questa architettura ha nei +confronti dell'accesso allo stesso file da parte di processi diversi. + +\begin{figure}[htb] + \centering + \includegraphics[width=14cm]{img/filemultacc.eps} + \caption{Schema dell'accesso allo stesso file da parte di due processi + diversi} + \label{fig:file_mult_acc} +\end{figure} + +Il primo caso è quello in cui due processi diversi che aprono lo stesso file +su disco; sulla base di quanto visto in \secref{sec:file_fd} avremo una +situazione come quella illustrata in \figref{fig:file_mult_acc}: ciascun +processo avrà una sua voce nella \textit{file table} referenziata da un +diverso file descriptor nella sua \var{file\_struct}. Entrambe le voci nella +\textit{file table} faranno però riferimento allo stesso inode su disco. + +Questo significa che ciascun processo avrà la sua posizione corrente sul file, +la sua modalità di accesso e versioni proprie di tutte le proprietà che +vengono mantenute nella sua voce della \textit{file table}. Questo ha +conseguenze specifiche sugli effetti della possibile azione simultanea sullo +stesso file, in particolare occorre tenere presente che: +\begin{itemize} +\item ciascun processo può scrivere indipendentemente; dopo ciascuna + \func{write} la posizione corrente sarà cambiata solo nel processo. Se la + scrittura eccede la dimensione corrente del file questo verrà esteso + automaticamente con l'aggiornamento del campo \var{i\_size} nell'inode. +\item se un file è in modalità \macro{O\_APPEND} tutte le volte che viene + effettuata una scrittura la posizione corrente viene prima settata alla + dimensione corrente del file letta dall'inode. In questo modo il file viene + automaticamente esteso. +\item l'effetto di \func{lseek} è solo quello di cambiare il campo \var{f\_pos} + nella struttura \var{file} della \textit{file table}, non c'è nessuna + operazione sul file su disco. Quando la si usa per porsi alla fine del file + la posizione viene settata leggendo la dimensione corrente dall'inode. +\end{itemize} + +\begin{figure}[htb] + \centering + \includegraphics[width=14cm]{img/fileshar.eps} + \caption{Schema dell'accesso ai file da parte di un processo figlio} + \label{fig:file_acc_child} +\end{figure} + +È comunque possibile che due file descriptor di due processi diversi puntino +alla stessa voce nella \textit{file table}; questo è ad esempio il caso dei +file aperti che venfono ereditati dal processo figlio all'esecuzione di una +\func{fork} (si ricordi quanto detto in \secref{sec:proc_fork}). La situazione +è illustrata in \figref{fig:file_acc_child}; dato che il processo figlio +riceve una copia dello spazio di indirizzi del padre, riceverà anche una copia +di \var{file\_struct} e relativa tabella dei file aperti. + +In questo modo padre e figlio avranno gli stessi file descriptor che faranno +riferimento alla stessa voce nella \textit{file table}, condividendo così la +posizione corrente sul file. Questo ha le cosenguenze descritte a suo tempo in +\secref{sec:proc_fork}: in caso di scrittura contemporanea la posizione +corrente nel file varierà per entrambi i processi (in quanto verrà modificato +\var{f\_pos} che è la stesso per entrambi). + +Si noti inoltre che anche i flag di stato del file (quelli settati dal +parametro \var{flag} di \func{open}) essendo tenuti nella voce della +\textit{file table} (il campo \var{f\_flag} di \var{file}), vengono in questo +caso condivisi. Ai file però sono associati anche altri flag (l'unico usato al +momento è \macro{FD\_CLOEXEC}), detti \textit{file descriptor flags}, tenuti +invece in \var{file\_struct}; questi sono specifici di ciascun processo, e non +vengono toccati anche in caso di condivisione della voce della \textit{file + table}. + + \subsection{Operazioni atomiche coi file} \label{sec:file_atomic} +cvs add + + \subsection{La funzioni \func{dup} e \func{dup2}} \label{sec:file_dup} + + +\begin{figure}[htb] + \centering + \includegraphics[width=14cm]{img/filedup.eps} + \caption{Schema dell'accesso ai file duplicati} + \label{fig:file_dup} +\end{figure} + + \subsection{La funzione \func{fcntl}} \label{sec:file_fcntl} diff --git a/img/filedup.dia b/img/filedup.dia new file mode 100644 index 0000000000000000000000000000000000000000..972233cf888a37c14bb712636aa302bef8155901 GIT binary patch literal 3049 zcmV_Ho2HO*2<^?f9($f{p|`?-r3Kf)}J(&T0dfwTPW z+oxYQQSb}@yUl{#f;UKV@$F`LUljXauC5**A3^+-2Su8JIC=nic=f*^j)N=S=xX`x z(_+!=U=tL9xK>{ciXw|{ABu311iSENc^j<%+GgoPvRPKG>UQfiPP4_2Aii0CzAOJM zuj+2Dj`}&#_deK%S-acaKFuTEqOmmjA%vcv!*~(5`bEV0MP&L#MEPo;WAl}YMUkGl|GOa0FHxYn{DPjbNZe-8<}?tGS`75^7;TFC)z4Fp z%K;Lvz3Tr-TmL_zJi3j;J`JLzkbd9K-9JfoFZ-?^qD`2edE3Wr270=$n_Zn#yxs0n z4XR76fvOY{2Tx&EcmMq`L@nxPTm!%H6w=%OgzKVK@83m`Y=UgF_`3LKl!VK}2jR|Oa(w__43|qYWVao?`kPp*)oQih)1N&? zi)4+K5By({R-<)Fqb)i28kb~?CqMTv4tJ|{nkC)EjVhf=5oZhsH)l(uJHHR3?R{~| zEGJ|7HqAC+rqAy4`}A?uv$Q?GgqS6|unKg+sm3w_T~K`1=z_r0jxHz#0E?~1w~`Y-{4PWLf$+Y_LeO z=T#gg+tYV1E#mC+xln>IC2pl0N_nfZ!@n%@#Y7P;7l(g7Liq5HVf|z5 z9RC=1T@tNZ8c7hphd+xRf}qmg1dbF(^X!(ozF5{f{xt%=>o6hEpC+*okD>Egj$KTx zHbX;6>9ap-*K+UgvveKi`JxDJ<8Z*!f5KBYCqED*0UN`wY+J*Voe-uF+t(!(T zURY0nef70#Fen5AWaI6Wd$v)FtCY**Ak`omcA_2 znegEnSWg`3)!&3oo!?sTt%TKjDjZCDt=6ey4#H}kGUi~yYCC%MH?dax3SLoPh0$UI z5eL5!abVhgqS$&wtw&UHZ3CtEPq@H`guyR-(cw5yr)$&&9xEj|0DI)RAsBk(?XPo8 zu5SLGK4cLm5CaPvPxr!R(7^2aM(ger>Fp`r7Yg+9f$w?5<72H)7-rW#z{qomkP0D1 znkS4c?fSQ<5F0eHL6b2-6Hg*&La?HsiJ1HBkCYiVUx(=2hSV;3^fAQOEdS~&c=kb$7^h^S}vw4Y=6#eu0K3bB{WO!CD zaTK8oo@rpg%D_TednR?l1s~wzn1YLxeiktA1u#SzVDRzkMH^sT;Sh4g=6@z!AHt9k zH3S+d9X}puBwkCzXII&(yTa_OFGDK+n>#v(JW5mvJOxOQesFRjq{N8tiV=+hv7d%t z6kn%H?{^uUbu5i>Ew!9WQIc+k7lt88ZCncx!Qv2xA(%q7CfEo9G)O8@|tNR&=WJWC`- zh-4@<=FQG!=L)ka(+~7+1RN`QFiLirnggwv%!;oaF;kciq&IFR={)ES51kJX!B&jN z=}PSBS()McN(`R?X2$TD*hKhj_?7F;pyBtZInc@){%FHTMhzc1${3%SaBEeJ&&osE z<_*6`&5vyOs@5+EDq6oVW2+Ym*wN~RRh|*Mdil7k7iQNkYSu2*mBwBjC3|;}lD#`s z$`1WrlILV3?#sq|WG1vKt)PvpzL$U}QnP`lOtFCsAO=I`3EM3rp4`AN7Rjq-7x65D z{I3=N@~|#!+*9o!-8Dr!POBcLM~=!w#Su7SATbzeBnBe}5`z(&7|b4nlTKMK#%=>dLS@aDGPylLBLl5 z0cv0!KpX1-W?~&c?K2=t$sJ9}boJ}4Uq8e!?| zDy&S~j2zvQ|m8a-gO$V?%MDNUl z4emC7IDc9ym`(+j2uu+HQ9%S$>!LyI_$JS%RBI~W5@$mNiKPMwDxh|qV2li?8Zz*- zl7WxQQy|qDb_P6g2!yteu)kG0ICb>HlEDRJ;8`+IOa=o^d!{CIiwuNrVPp4#XCicq ztkeEo#jS?MLsyMQU2ouuxkL!5#zPJRmog!99^>IUPV;b;CadsgxV9ssj62F- zn5lsyshdU0dqE0Pg%lH61#7I}16CYESh4kQELzGkZ;H@jqWq0tW`(G$-=I1zgpm|Y z(i++nO}6;WNN*!iQ=7_Z2d;FbX>cj%A}G^U zD+pCaDa?r1#dBbp*tbgj3V};Jkq(&6E%EE!>UE21y-z-2z$SowT|Qyz_{0>OyrhwS zVH0P5Y;qR|+uX8=S~js<@~T|oDqQZE@J0BdJl{)6EeMz>&o{%8T6e3Rotmg$>e#wk zuS+MMGCDC*?$ZGdA%|+85YY0l6PX{I@UAVHC?ykH?b8&Q43uml{>*}kFO|xCk=0Rb z?lM%bsYl15U0|LqQ+B#c8EKU%qdiZx=jX8gIrdNdTzi!>s;0^rGF8_SHS1cUx~`=u z)by!2(8}WGJZ{j5@_yrSWC4?V`8@CAnbUem@@TdtSw1vORtG(jv}2p9>}QGRasTAsq`l!6J|x|G4uWJGZ3d z$UDU2wzY$ijA ztPITNH#U^Kj4CO;#tf8RV~x^lu8GoX%$8pJAmgEuEJd#V97Xj${^uM;?p%_5+Z;tw zqoHfZLd9d@P#8qI0-YE&be7?Df$uR7ix`MQ5We?$eX73jzuPR>ef#u({01F4Sl$2twNS~y literal 0 HcmV?d00001 diff --git a/img/filemultacc.dia b/img/filemultacc.dia new file mode 100644 index 0000000000000000000000000000000000000000..aa5a49e39327a70b8afeb42702d2c337bb9d37fd GIT binary patch literal 3978 zcmV;54|VV#iwFP!000001MOW+bK^D=z0a?3IadcJzJWM1sm-3YYOCh3xuv#Lv_;$6 z$dZeq!I)1t^Hw=YF@F-xDa&zHC9-5(G6{AD)2tXeJG-OZ=-{Nm4a z`uXyQ`|{7_^|G7mjed6Y{hU5$`F6KY&-2B^H7VYnYfW1E@jutvEL$yHquIlkAO0qO zs6Nv2jgP*XK4|M8#Z#I;OlI|Q@+_TJ4}uZH7+XDu~Y}3-y&-Dx?EyW{KfXvt#8pDX_N43I zW?TQax7*$4ZU*V>VVb=U!L@XQxSuzEJSMN)UkQ`l2ECilW}|F2E@yGv+*;aD*6owb zUY_orw?9A=Mvm#!F?lvBDWv{fKj)O0Oj zJzK6N^xbgXXi#=rn^kKu5_0y=-pCJ&FrF0)i!A$>c~$64N=-7g;JucHRncE1ZTNObWS z=%QVX5kwg) z%26p7tmlnaZGQD8?gP0GCx^H5;vF$Q8;{aFpTD*nFAMB>G|grYyFY#K5PP4`fg^ZR zau(}gwb<(H<6kZw9T2^5?{HVl{j#PmFFyWx1MTg>)$e#^cU z4P+sMPZo&j**!~$)Yg0WiM?UO>O}bgZMP8%{}^gt%jR*@R-3kEr98jiXt#CL|D4b7 zvc=+}NN=ZE%c=j4Q@gfv+WD+#8r8qQZ1UUWDO>#bk0PB;?$(X)_`zz+ej}X9v+j3M!ZslHOUt63f+! z7APf(ayk%RxSzO5ASncsLV~Q&3oEqv6*`7r;rzsY{fhD=SH8RLrn_Hyls~aCujVGE z>(uciH^6F5jKijWtu|T4AH3BjW&FW-+wIwEYx8PuV!E#4Xtmu>NNo(G}VyRH{$~hfLLi;=>)x@ZBq=axIZq^2-M*Q{t97ylx@AH>@ z;s^x5u`zu+HmwGR{!Oo$Dl|%#mFzWg;0c_zG$vAA`9j51v$sFh8Q@$^wy-py__z|0X(&Op? zYBbWCBx~J3+LpQ9)UEI$p!lHK=kH;5jlTbG@4wR!4X#7|3?QHutN9e5iI)Oq(tZ{Y zP|Q?EPdBuPcxYizXrU{#I2#5-3q!OZT4XG=@Q^R!7_>M?_5&>p2rWUgL$sU=T2wT& zz+i1AX%EUSB`KTW0 zsKq%l>Hix#G}|JZCI&XktU3m8px_3gN|rFOnwL48+=y~)|GNA5&EdMS`5Vn1m{S*kY;Ro>8p?NfXfm6RPe&@}$tPPjhx>3Mjspa#gn<%FXJ-W5;dH4n1Io%}r#;-fTNZG~yMyjhUi>v5m%r$O96nx3U^# z!&BXr6v=n|dP`blM7TuB?JA2C`p3)ip4$pA%cvq8V(OD@t0z(-8r~zyL#6fKecM`Qh_Jz?=(UOfApsC*B{)?FjF_}bT+T@A3gvQ#H5RiR| zFsk%-S6m_#_dAopWla)7kVs-~NibjXw0Q}f4eq#3d$aK}Ty%AzcLEh^ZJ1_DD}zy^ z-BBa9m7b7*#!7jVbR2*D1!MNgAGfW{zB+URH2a2WwzNXCKho?Otl5ibY;T~rURP-~ z;6`7YIk-V0EvUYfster}Lw|}Nt zNek#Xcvq%?z zjNFTty8`2#ahK`3DdIXEd!0UVRgR*(Cc0i#euRvbC=XhywOA0-yNs0x(wagct1}g{ z3f=}s$z2jefoy|CdB$07gPn&3w+#-SAZ~-tBo|jCu>b>cnP~->>N3*`FhF;i22T(H zb1s0Pu>ixt;9}R{qM+b{S7jqu1d9b02*HvHE|n)#!A1C=FmOT55(JC`437sG0|uB6 z|3$+2FDQwHfN_8k@f>~z=J0>4FcfZup}4|e9U)+VO+?9kQDwwd0YFn%0k$%t=Fq8p zfQ?p_g+mi!zyMnx0k#HH!~h#~9gtA5SOr4h#Y@yDqSSZs8FiX4WmPHfGO&cY`ExcK z-H-8((x_~L;x4CV6CI09Ans0g-gSA~admaNA~sQjyf}UQd-882l9)t-*QTGENK7mu zfe>}6h-9VdQW41z65(&z=oSH~%EFytWo0CNOilLR-oFd8>3=L3h4hx1N z6A9|fK@mxFU_?es?BXD&uRbus%PSUFp?3zBse%_QVnL8Y42^fP2oXvY+U?=#a^-cP z(NdKKK?7TP@22xbHk!{y*|+Qt*WkFvi?{}#bTcnmv{M17t^7($ZMl^npq3hLr!q_E{i8_7d!3ad-Sb&oZLoN%`t@lK%ff8Y4zip2Vx#FSF&@*KyE+n#~?|fBN7d_CB8jM`*mt zYTrdxW=kqd)C_Eg=8tBZzg+tsYagkn3P~wqX=c#`LNd!J|m_^-?L;+}(gw76? zO3oy^SVj|=voHd49xZ$gEeQ}>EY?OMT)s*b3oZsAH?M??DTU)oxL6S3xZv3#TFwP6 zIv!dW6k6yCEe1q2E_il`mUBUiiG>yo5YMc%esv`o$Cj72g9J2#XNUn!tn@lI%n?U1 zE+GculI?_0B}{*h->tCWv5D&%$t3dL1ar<|$fPAdREdFw6}69z_#5%8kC2o(UO^dsr1bgT+~1$Gy>TDuEe z!`%h0FrgCf0{^N^EWl_mEhD|AWn|#Aj5Ox!BVfL&Xli)|3@&yJE?`$DiNvCRb7CTi zCa*{nI5i`?sb=Jd9#|beUV$E4_Bp|_79c8V35`U{?J{6;MrKXU$im4P8NB@q<%}F+ zY`n8YFgYW&DQBcn&IlLbHao;M7EGq@AKiIv8&G%l zyFQ;5SAVCYe@y@FPX0a@|7fmU6mQe4ozBFbuH(Rq$AFhu&jslTUZTv^uizz#=pA02 z=Y;S=c)i0*#DG`-YnLnwEh}(2-??{i;mU>3Iv84QuA~gbmM$-_lRctK6K#y9SMG0R z_>Co8CemjrNJ^RQ*^#VGuT4G%y-4&T5BDN<65vHj^A{1uHBpk@{8}afvS(MTG+$e# zL2eHTo*+h;&n3caqGWebwJ@)ftNc)+tci05=4;~I$V01%E7HXuSQFRF1;%w# k#Q0FO_)zt7n!aWEmrvCT_y0qlK7IN0e=F*mqE<@*0C1x=UgP-=kwWNAa0Fl zndR$zRy<6;9eP|CIehHZ{Lj73|L1%)zg;9vE10K+^XL6C{j=lruAlYOe3q<^eA?S% zT4s8vhus`o`0lt#OtMhyNllcG~4FCz1^KY zH!FzK`$h69g2~7TF<-}49*sukFHECuLZ?}pPLgz1uHwA4wTvOO+dE009;eIQH_(KU zb0#%Ro=i##*?+EU`oNLH?5pB=k?hW%nAKFXA5(_v#Y$7Vt1fX>U5#kZnyV3cRa_%2 zl-}+wta%7%ZJ%2EYxb={X{oEynvH)%dsSLoDs9QRV^)$a>-^l4Me;bAW_h}A-1u5k zDdLFYFhm_De@N!{55*z16kQ>Go8_}4?@#Yn582mAgK2x*gcu~cm=AQ3uF7%-x`_Q+ zql+NbJGzJy003P-7`j?cT-+62M&S+7lOEy45K~fWbNtav(uj>Y(!?l`6-y{3J)gYx z7PvozBW2+~yrUQE2=a6`iSs=B+OECSapuV)N$(H8duI_xpU;UBtST9mHMm;sOt$`? zs|SNbYup>)6`4IX((9}Be{aFP{f9~Y!whf#Fx&S}?7XEj+2Tv`t!QA2$l0}Ekb-+Y z>PAvq6Cdj_MOtEE1?p}R3;P)MK9+5N)6ST-eWi5ZZ;jjW^)K^mnygk=MSQzRTHO8z z+;(k_+AJ-aq}tc(Az$W?$?C&Dig+=fZYtsV!uIz4MpSV(A=?Uel9F{1QwE8e1Z_r- zaQVwkka_I)>0{FTF|7%eoG7KyKk4TP(LxHsnG|sEtf0-=LA=lcAxIEL2Eq$>bF&B_ z1!q#gzzV&vLW^M`eHa$TQ0&*RC|$YHtKF`;8>VO36I<(Q9-_J~9bCB%TC03`oBGvS zTn8Ym*5Wb%p{(xqthIaVY96Ax?&6@e-Cd;GhtjeD;Rn4Deh|GoNEx_C!9D6|+Ysku z3W+q~f{cvOfidaRPb!fTr6i1);^Pg$MDg$6&IxJV{5^Zh=Y~K67&fYJ!=_ciz`p4< zRmC}1MU6P>mk+ekOdBcK{yo-+al+{+Lfrn{^MP?^bQDfuPChK@;T=G~wJ+ z(8Qj7mRpNC@4QavvFy}+@@Q~qnKSfAxa17)u}Djd5cetCd51?*jgGpO&T%g7xR>T>HfxWd zA9P@x?q_QCG=2CrTg&{v zYW6|(&nUthqlgfvV~!Z5${va};mq#%n95SN{eDoKGFi?4cR5mdn|!jPgTN=j`9%8T zlMrkol&}XBQL%~nhhWxmgonl^2qB;nzf=N55`;+FLS$-iZaZmR4>q&PN~O_AZl_kA zE4ejVcG@yqMoAaDZ#Q!0u}DZ`{LImb&=@8<9w;JgJJy5uB{t0LP4TrC#TQ70QG9{q zTJb9fTtLNdSZ2#8Q2etMp9WQYioG$u4B_0W7++RZXo4$#!!mzl#rI{uP~y#gks-qC zwFP57=Pe6HR{jyNV18r^W=8?RhUsp@RIhC0?s&=NpL;1UoQi0G-5DcBgstwO%J`>IFve_UD>}6JXA!Udn3!*#rUgVn z{chCzstEhE?|u5rU77p162}8n4dWYC!+3zIVH~Q4!L>O5DecrtR#R0+tAD=_Fa4dQ zbo(eD%7~gu2o|<~-q4ujZuT4g9caWSjW8gQi;@WUMItoOi__Bw2<;}GiAX~IP%(J>0Vttrr!z+dehk4)5MJR-L znLC9o#ci1O(b7~P-ET`%C1}~A!~Q)sCv9ndk0cU`DHfo$>DKz1kNy%x(Detp{+!(P zCvxffBgA*o^@n@OnABxanEvx8G$Ps-#?oU#5ho*K>I7(E;=DTOVDd)ti#hRy77@TN zP@+X3`GOXs!-3EuAh{UO@|jbAXrZCdLSE1krk|Yi>HsZo1ue`MT0&IkEzwdnldI7} z1EB?a$pKo*wyD0*5&|phPI6^w!%&^%9M=Z{O}OTDW|)KfX(Wfs>gxe&ZDT}4MAx0< z2x5w>A-0mU7ro$ym){zS4QdDhkI<1*F1%5S4B~ZBn3N^-tHS97Nv^mRJ-D3e$z|J9 zzD+)nkcn|&K9L^zgofgi*G3Gld@{T{8k4(4d=GamM zlmv;Y&F%0mj!quoaN?UxAh+wXRHFS+Nr)DG7-7!WJ+ldluoz;?>^u8RflB;R2_%XJ zB9oTP&)$>ZtxK9=?2evd2f-I9)eq!ID6_LSaz|0?IB2e?;+TEP0&NI zQ?l7WdI+8gugFh}P8Fa<=ek{Xgm{1!oeJOu@N$Hg@By#>_pYe45G!yABzgxI>|6k? zlcCjSNlI62sS&|liy)i?E{U{?n9V+*QH0r8Bc{2k#1bxgwj+0!*A@o=BNB|r(~U^M z9gIlMzmqZ$k(V5%aw`iE`KUH&v0-4!FuhEj7YH}1-pWO%$WN+{P2dcG7iPOz*~A=s z$;qgfZDu8_J5NK((<$QBAJELImz14dMTC5vP=(!E2u5IMTX{sg9kb0a*AiMPOW&W6~KKwg-jMJTX<(aY? znd2C5oGWCXGmdCi7a>h-aS~UYE2xbp+KrvVyJ0g!oMYU(9@qu(RnuJt>vStOI^C*p zoo*!*qk`7Zp9S>=7!|CSy4vWauEX_GS5WH^0P|TeUx3lU;G#F+B0|AM16Tko+!t5~ z4%TCb;Eg6b_RdZy#JH^yK=W2W6L|!U3J03C6+=ikGsbO=0GhV~8sX3Ir@;*W^*$rR zZ8H*f8K`|2FeE6vb&Zn&g6JG+8x*v4gltgI;Iaw|iXj$0grHzw{hlOTfqP7FkI6uW`ExIZh$jlkUz@2|)X2!X7YEl1VYGp6c56^ z7Z2*ZCMX~DBbE**4s5=fqdX;c2j(P9efNenHV+amnG@ebiFekAf2vLYJf**h zK>8PL=${Czf8rGV6QF-*>7O1h|5^RBHT%CS{&NK4o7KO6WsB$gENxIhgSbmwHm{m=*{G72T2_j<8kf;_ zb5if-B}a+~T6VN5?aNZ$U@XjR`3weTcLOup?|cg;=5Z6V`hF2VC;6v$)i>tPeI7r4 OdiNJJ>n{FiF#!O_Rf$*t literal 0 HcmV?d00001 diff --git a/simpltcp.tex b/simpltcp.tex index ff33a21..e592f2f 100644 --- a/simpltcp.tex +++ b/simpltcp.tex @@ -17,7 +17,7 @@ durante l'impiego di una applicazione di rete. L'applicazione scelta come esempio sarà una implementazione elementare, ma completa, del servizio \texttt{echo}. Il servizio \texttt{echo} è uno dei servizi standard solitamente provvisti direttamente dal superserver -\texttt{inetd}, ed è definito dall'RFC~862. Come dice il nome il servizio deve +\cmd{inetd}, ed è definito dall'RFC~862. Come dice il nome il servizio deve rimandare indietro sulla connessione i dati che gli vengono inviati; l'RFC descrive le specifiche sia per TCP che UDP, e per il primo stabilisce che una volta stabilita la connessione ogni dato in ingresso deve essere rimandato in @@ -124,7 +124,7 @@ delegata alla funzione \func{ServEcho}. Il codice della funzione \func{ServEcho} è invece mostrata in \nfig, la comunicazione viene gestita all'interno del ciclo (linee \texttt{\small 6--8}). I dati inviati dal client vengono letti dal socket con una semplice -\texttt{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura +\func{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura viene invece gestita dalla funzione \func{SockWrite} (descritta a suo tempo in \figref{fig:sock_SockWrite_code}) che si incarica di tenere conto automaticamente della possibilità che non tutti i dati di cui è richiesta la @@ -145,7 +145,7 @@ void ServEcho(int sockfd) { return; } \end{lstlisting} - \caption{Codice della prima versione della funzione \texttt{ServEcho} per la + \caption{Codice della prima versione della funzione \func{ServEcho} per la gestione del servizio \texttt{echo}.} \label{fig:TCPsimpl_server_elem_sub} \end{figure} diff --git a/socket.tex b/socket.tex index 3606904..b8d1a19 100644 --- a/socket.tex +++ b/socket.tex @@ -728,11 +728,11 @@ socket comportamento che avrebbero con i normali files (in particolare questo accade per i socket di tipo stream). -Infatti con i socket può accadere che funzioni come \func{read} o -\func{write} possano restituire in input o scrivere in output un numero di -bytes minore di quello richiesto. Questo è un comportamento normale e non un -errore, e succede perché si eccede in lettura o scrittura il limite di buffer -del kernel. +Infatti con i socket è comune che funzioni come \func{read} o \func{write} +possano restituire in input o scrivere in output un numero di bytes minore di +quello richiesto. Come già accennato in \secref{sec:file_read} questo è un +comportamento normale anche per l'I/O su file, e succede +perché si eccede in lettura o scrittura il limite di buffer del kernel. In questo caso tutto quello che il programma chiamante deve fare è di ripetere la lettura (o scrittura) per la quantità di bytes rimanenti (lo stesso può -- 2.30.2