From 8350dd34c88cc0c336fdc33d642320dde1e942f7 Mon Sep 17 00:00:00 2001
From: Simone Piccardi <piccardi@gnulinux.it>
Date: Sun, 9 Mar 2003 23:16:52 +0000
Subject: [PATCH] Nuove figure e revisione completa dei primi due capitoli
 sulle reti. Aggiunte nuove famiglie di indirizzi per Appletalk e packet
 socket.

---
 Makefile              |   2 +-
 html/index.html       |  17 +-
 img/iso_tcp_comp.dia  | Bin 1945 -> 2024 bytes
 img/tcp_data_flux.dia | Bin 2395 -> 2637 bytes
 network.tex           | 371 ++++++++++++++++++++++++------------------
 socket.tex            | 322 +++++++++++++++++++++++++-----------
 6 files changed, 449 insertions(+), 263 deletions(-)

diff --git a/Makefile b/Makefile
index 21e5740..570d4c7 100644
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,7 @@ gapil.ps: gapil.dvi
 install:
 	scp -r gapil.p*  piccardi@firenze.linux.it:public_html/gapil
 	scp -r gapil/*  piccardi@firenze.linux.it:public_html/gapil/html
-
+	scp html/*.html piccardi@firenze.linux.it:public_html/gapil/
 clean: 
 	rm -f *.dvi *.log *.ps *.html *.aux *.toc *.rel *.ilg *.rip *.ind \
 	*.pdf  *.out *.idx *~
diff --git a/html/index.html b/html/index.html
index 9309c05..ffe73bb 100644
--- a/html/index.html
+++ b/html/index.html
@@ -180,15 +180,14 @@
 		<tr>
 		  <td valign="top"> <b> Cap. 12 </b> </td>
 		  <td valign="top"> IPC</td> 
-		  <td valign="top"> Pipe, fifo e code complete,  
-		    semafori memoria condivisa quasi completi, tecniche
-		    alternative quasi completo,   
-		    IPC POSIX da fare 
+		  <td valign="top"> Pipe, fifo e code, semafori, 
+		    memoria condivisa, tecniche alternative completi, da
+		    revisionare, IPC POSIX quasi completo. 
 		  </td>
 		<tr>
 		  <td valign="top"> <b> Cap. 13-14 </b> </td>
 		  <td valign="top"> Introduzione alla rete</td> 
-		  <td valign="top"> quasi completi, da revisionare </td>
+		  <td valign="top"> completi, da revisionare </td>
 		</tr>
 		<tr>
 		  <td valign="top"> <b> Cap. 15-16 </b> </td>
@@ -199,7 +198,7 @@
 	      </tbody>
 	    </table>
 	    <p>
-	      <b> Versione corrente:</b> 445 pagine.
+	      <b> Versione corrente:</b> 467 pagine.
 	    </p>
 	  </td>
 	</tr>
@@ -213,6 +212,12 @@
 	  </td>
 	  <td bgcolor="lightblue"> 
 	    <p>
+	    <p>
+	      <b>10 - marzo - 2003</b> <br> Completata la memoria condivisa
+	      POSIX, introdotte le relative funzioni di interfaccia,
+	      revisionati ed ampliati i capitoli sull'introduzione alla rete
+	      ed ai socket.
+	    </p>
 	      <b>20 - febbraio - 2003</b> <br> Completata la sezione sulle
 	      alternative al SysV IPC, introdotte le code di messaggi POSIX,
 	      un esempio di uso della memoria condivisa, e parecchie revisioni
diff --git a/img/iso_tcp_comp.dia b/img/iso_tcp_comp.dia
index feeb0dd1bdcba97665ed2726c55294f980ce7d2e..501183df4a65ffed910995c2123753d53a3cb266 100644
GIT binary patch
literal 2024
zcmV<E2N(DsiwFP!000001MQt(Z`(Eyz~A#J4ENQgMN)sLrb)4`7*MQOizRzDXp6PA
z%90_;P11*b_K}iOTecjhqRx#{CWryc^qolY?#CmK%<DI|%V_Xbq*<867ekD!;XuT*
zBnadA#qgi&KVGuoo6ED;LC9apzj?}+1Nn_OQ|~T@i#%Vw8jo*oZcucW@jOXU6s}Pw
z#{cms;$vB8JiI&`47LRXJm>0Kb(QCN8cx@_7{q)jE{0P+`!Y|HbsP-KQdPNG5+&*2
zD~~RQFFqGP!*L~MT$A&F>=j>$bXV+hm1LnTlHaZNiX4!mUbo6rr7~G4o?pKB&3;kd
zQgvY?tLa7$D#@2Torm$ho>cItYzTrFA>_Uteq6;AUPT12B868GW|LKt<|z;JeKpf0
zi3E>JO?kQ&?e%0c9?35AP*rey>7T<qPmbLGXC7sbsX%%8yY>92CC<|@c-RnYB@Rfr
z34?qwxdm#jQu-Z`^siwSP9xED_hFoOCjL%SyzX;ehk?kBJn4Fw1Ckb1vGK8r@0NRP
z4a!S9kSbI}{7$5m__rH84XQS-jDD*XlIg!<mRHrg%6S~{G#I=byiIP08`?_NhQY<~
zqg8L7-3m!z()sMQ&nnqGM>6tv>%0FT56PZRcSWc2=6O7iL?s?0-x)Faa!xE{IU{+&
za@r{rkyuV<NgD4%wv!4K@(aV=uhhNKG7ZrS5zZI+VcDde>}iq)B0YBF7Q*eshp}w$
zNil-jmA*Z!3YhwBry^S<H<O03+i^xVJCpIoj#?WQ)-^0TqJVZqlv$~l^TMD;4zN|V
zu8lFOU(%?q#ckeTRYcdSJk{B4L;y|8M%Z)Nh$4p(=AQe=CzME?RK0DdH&?B(_nhk^
znVm9+o@x;m*2?WhkgHV`&Uh}{{Xi)Bz;N);;6I7;CY|bfRpj?%orcndjCJ(v8FQn}
zF+C;q4)(ZC)<(~+bvIhLRs85Fl40LGUW(>NB;xh5VZ{DWNYFIqg+wjYN38>mT6=?9
z4;;0QL9IcpE^6&gQ0s!CmP)p|a_m}?7RzVs*-~XsNc$-jne@5_wYsQv4Qfw>T1OwX
z9yDs*4QhRG)OrTB2DQ4Vbvr>V14XTahzx4I3bhO|8Pl@9koHPsnSrbxWSN2Ni6HCg
zL)M3eEZaa9d_{(u1(}~gS+0Jc5oK8?l$Ajy?Bua$GbRVF_mjue!9*#Qr1hUZXs=Tq
zXDVC8pjHF5^*&};3&>hupS2i6!&df(4Q(knZQEAJ;MN4STL}<WH@qd#VJ-ED8pBH9
z`YNt<2~$e@!P~z?ev_nM3~hC2OAKvKL|fcJRul$Li^5xZQ5Zfk3Y*L*gIj&vc9R-~
zp>v~rM${O#pskNEW=ds0VEc~eYKMfOtrl%fUew8G+d*O!2G5MbTd7ePJ~s-R<S0X1
zecE=D9fe(J+WHPrW7vD#S~gQk`@!2!i@PkG@yPI2hqop<>SVliI@nA{!8g;9&1O0u
zelJ~5gIm|&_9@|3J3~skLCf(Oa6YmOY%z1UGLjkcDeX^2vf2Bi4c*3$X0Qv1U9SV|
zf-d5g+$~pet6l6Ap1fum*Pyop^s-LS3%!o3rWLmra<OMta(_AOnx)(mQrGW-y7191
z-U@fYr<XOV^s}jJ8|wZH>V61g(R9v556)#`p4tW=UzK%XqGpriYdf8@B#tK{4vGpq
zzFPaA6RT~trOTbIb~QI0SN0=9Bl&ob8^>c?O|_DI46>(Wd&Y48$zUP-mO2+qcBMQi
zXC()lk1vMKUh_4486Wtvw|}(R&MkG+|M64b1GDM<(iBeB`{~1-A7j(`>z!Yx??ZR}
zLq{Bujsh+VdaARwQw1}#Rpplqxy)Xb?nACau7P&741yg*ATxW4v{~0x$vrMDr(-Nv
zCEp;M_Q5%PFlm0;D<C_4%(w<n*Px$}G=kk{WBZou6LN4MM+xT)IhIdG1Yz~|>HC9^
zSMSH~uRfmAC0vI~k-hvoS@QUKWFw8tIN?;zKtB=51@#6J4cKM&cXuF>!Kl*N7k}_B
zd1riq&Je*kgU+47p{X?O+$n-#=hCe0sbv3TlWFy8HGJ+r$Jw-w2&0{ILx4{L#K^U6
zm4;=z*k|X&M$~c0NTmhH_kB1VG?|GkOU~q%;#@pq+IY~ksdqI)8&Jo<I&ciIC#qoN
zyR4X~wq2qegGJRYR4j+2Js5fZDbiR(#vN$61B{J7IFUclP7@*?@R1KTay`pai9)sv
zMdbjLdVaA--S2}xkmH0rk=-r|2SGSElWNv+IOE^sQ!s-D9WPPucE(FUdI@TE;3YtJ
zsyk}^${yMG;e^`QQ*89<PdKsdCV08g$9M^SFJYFrPBf84aR*Mqg>(`wQvXQLSJPM?
zDpHRv_*tx4otimDdN+;LHcdOrd74jnnkF~9;v2hoOWBi1#Pf%1pkIOGt<*M`Jr01H
z=(}XN2HL35Zk~?Z66s*ZgF(6_g4919E8G%AMaI?%+)}Mh%|W<j+>&ui#w`JbRQiX1
zQRLdbH}YZsg&RTGq27p9dBoH~*mjiGo}8JGC9^NWBoVg^pc*@wiK9RVEZV7p6n1YJ
z@zr2Od4zLXgivae0rbwABm2r|ANQ46hQytcxO^Y+JCR<Vm2c$VJmt&Fv;P4(4!@<&
GiU0uK>grhl

literal 1945
zcmV;K2WI#miwFP!000001MQt(bDKC2z~A#JJnpM2BZ)tvY0|k~UpjYl?Oghvk!{uH
ziopX)lib67_LG3r#>PpCSQ1iYCY}MyyOvn(PrIz}+jlqXc=TOld6Xt+V~m{fyYrK`
zi-^Bb|I3W8N2)=R>!Y*rO3KZf>Gb;g8pXFcmuZIL=nCax`X7&DK2?pT<MWfzXjj03
zORmpVXStMFG`o^wl<>7U8_)Rs+cHb9lEt`eRkfR^ahi?3^Z0E1>TB^go>pR}H97al
z-tdjc_QkF@X&$L2@^*93<cJ*oy3?j=m8(X{^8D3r?yK@ERVTKxn!e~!C34NPWt1H1
z$pnwffgp$xLhi=l=T*$$RmAWrGI$kHez{3Anej*-s+px}EO=6ClG&ALuP2}LSeeXy
zUBT_8e~qL}ANc-Xd7M9{1Lf%-v*%}L;xdaC_fN!Hiz8C5qlH{u-T)0(Dg72m`u8Z0
zX0d4c_E91`6Mt(c-t;<OMGKKXaHZ>Qj!0Tn&881^e81gedr+R*gH)j+=C>lN#J}I-
zX;h7IHR*RoA)Wmr=CbPEh2+VCXN%G6(fjmfyoIYX9z~0@@h7J~Jo_C|!j$tl7@tkL
zy^drO?)UfbLLQSno9&Cv)R*VUG8UD1j6!e1)XOPxkmF6%3CC-vP{d+=IZw0X5VD<g
zsE}Vw+`~@YO<HCkdL^ReN*<R@+R4sW>Gfs9%I9IiG*89p)(TsjB{nrnI-!78NwiVw
zm(#)=Cmyg(w(gBJ$rdL0Mcl{+n<S<-8E8{+5dkzzC7n@!LXqct9ytvW!@jF@QhnG?
zuhgTlr*)sAdu@(g)gmORwcC$gHk&w_bE(GtNEma^QsmgeGfiZZPJO;=@_TxfMQQ?0
zP4pa0g@)<iAZDhdZeWiyvNn2(fVWB0ZY1m!e`bnQ$gxb;qWKbu<Z9ipTD)&L+O*z+
z1Qj(0l?M$fcMGZj98{hK)l-AY?F3XlFsK|?t+c%gR9LU=8B<CJLaNW1$d%W!s4_*B
zZ&B3~syuU41<<JSx2OuiQ59HJJvFNQPEf@_QRN}xQKFVkC8`)=uFsUtfspD#<hg~E
z8KjtnR8No!%pny*LyB!71)hzjHW~f&lwzGwO2s&^5mn$bS1p_FQh$_UUn|v|dj6RD
zlJO+h_qi>o3_w-4F-s~yQibNE!WbG=${x0?qTsA*+aU|9?qG$TZfHgN2&$B2YFym~
zRZ8hFX!Vzn*J<|6vdV;2#ImX<R^blnDKL0J1>UKs!0;s%*w$1$J*>JZs=zKVtQ_nx
zy?`oU6(Wa)L@ONztUhq5D|;=ijA&(RDte<;2SpVays854lvQB(x(aLyE1sTK-Bea!
zzZY70bz1oYq1ETrZ63{eY-wdeD_d648?C$!wop*;Efi$Cg(8ICK{3$K%700)GOn#q
zPQ>v-23!fKqAC(ncUua`5F<VrPAQ-*S~q4^qorADK~gK|fLfsUuS#r{H?XR$e-s{E
z_72uFAQ$U|T+p|$bVg|R9u^MlO{`xITJ|nhkIV|YU>1C+g?C~t@XVk=m!6tg?hu*v
zXOxJh&A|hBkOB*I?W%g!wuy;O1gO_`I_GJUT#95-bl~ybI((lvZM&@;)_k+Cx#{^L
zKO;0&m-nGL;h@KknjR%}8I+~u2TZ?vXS7nbr61&>Oi89?LTR*p`)uqT3}3^C@sSS)
zhtDF}`$`?zKYs3o+gs~bQ=u>Gr}rB_#@6`j#&2T#(58Rvxe%nIaK(Ynv(*a3F|!ro
zzhuB-OT@bmSdO^{+Eor7dx&_j$&4^`ilQbTm&puFLRaf`@esVjpSHlsIQ_n7WY#x;
z`Udl2k_l`XiRbvrA*j`X8{kuh+>o*fL0BI?e}C}l;^Xw=#iu@9!k1_*^4EW-Yo5G}
zN|K3PDD>qF%!^2TP;a2nfQd_gxC4a@6-o!g@dqE$57rl$ED@|T=-e3`%cU7t?hp){
zOmlW~$zgBVw0gH1-Va}5I;|tZ7#DmH;O9SK<a?p6`*K|ulT+d%>N;$q@2acgAv_W;
zor^qAPt=DJDPAyb0%+RQP0i8<)G@FQ90Tl=3@{2^ugFwu*PuOv<GHRbyus@D`Fn;x
zM3#uyIs_w!fU)%mJ$VG<IvWxIZx?qF^J!6PS9%1s`lLEpMT^D4Al3>pRfZQwqeV12
zQEH+jn)83vb+8Ku6F*TmJnJVQ{RDM7@Drf>bUlQffKA-HkU~YQA<<8r9!^NH>n3=)
z)5LlSb1z|UbM=(WqPPPm;X^tJAL$?P33VzfKt=Vg1E0yN^{JU-WN@jhww2Dg<e9wW
zS(aY!i*GdXma;Enku2};fq4fW9;LSB;K>4Lh<-?h8=$QU<KgMZEs+kg9t_eg5u|^v
zrEp6W6=hpJxTRX3n!|9%x+UwDtXl#KsmvdJM3L`?!6XDNCZ=kU6ne^ARK>*9L&R~h
z(mIe$`*}M5CTt~f%K)m;$ZQ-1x?nLb7o@No%t)vgE7~KR(jtV?I}M<>*F3Pfj1F;g
fnPW-ZDT&MD;&-&qPijB3eSY#k5ut5nbAkW>q|eE?

diff --git a/img/tcp_data_flux.dia b/img/tcp_data_flux.dia
index 93a2e55526d4645e6dbc82555a051eb6178f6f15..39329096027206e3523e87f88b592f0a51517478 100644
GIT binary patch
literal 2637
zcmV-T3bOSdiwFP!000001MOX1bECKteb29;Jg**wmO#LIldYZ9-Kwp+dv9uI_SuCE
zvDv}k0y3HG!~N}7*p3}A{s@vtm~^I+8f>}S66&Kq95wv>%lAcWd<(NYN|UPr5OZLJ
z$ute3WOg<9>&tH+-N7%{7e5D)|C9KgW&XktpGflZ=xQ)8iset2mk$pQB!0~OBF#t~
z-IF}L{GT7k{-tPiIk>(sjOPXdzwpb~Hm~|ckwugHA~X_z5nc@@{`BiCOYf6lux_<!
zH%;R-Grsxp)!@V3>Su7dF>_h5bHw)2Uxr!T>|&Ybk!VspF87)ouv7kh)@IWx7mbqH
z^@m@r59_bAd0}U(>5Cq8QY`#z7A5<Bve1v$13`&PDSaA;m%EtgcM<D%k?D64<>O_V
z6`3Cu`)(#_8i#(e_Eco|VS7LM)Q`oKIo1_uZ~ZPRiuA<yzw_h#oDQsC-bT+$BXO2R
z!SO(>v^ZepAqtB5`1`TpGKt-Oz}EI3wb}m`<<TS#n|cr>#b)Ztn}3uvFMF=<qae&r
zob76x1D58SW|yZrUT=4957sZ$7OItt*nbSOjrmWzCCb>0@h0$}jY2y4JDe7q?tL!&
zB=EDq_-Ndw@#DXvBpmFPU9sp!!PVfuW_66}y%H7$3hfQjGToj`KD6q6-ana#Oiw0t
z%bDnapUmQLZQUmJkP*+ZN0f>Gia#c`+xc6HK^U*T_}SfQdYiIi?^AZVLCf(HARUfZ
z=&(O#J7h3z3F~?B7>9N1VRFCNi`$o&&I>;)#(tKi4~K0tY1`vCOlHRi$Ch_;@&vT>
z5hj7AA=+BjH$XcV(!;ZUaSdc=Als+(djqI}EU3YdY6LZtc=iy)pOGWtb!fK^+At0m
z<7t{D`}9FYXIAD<oKY@edLBlzd2!fw%LzY8vmne)Peo{FK1#%Jk5|;NZv8o54DIq?
zOTd|nP--Bhr<4Decv(-JapnineSU19nA(^<kcm*)ptXj!#-L?HtlY#KS;QGSZRgH3
zO_H%d%adtHr7ulyJMF%JSWKqNy5AjA=*&!dpFKDoWDicCvj<0e_Hd?$GR#Eu3V6x)
z5c=sIV=e%xBvAr?igcAU7`t~X3)|t(!sfG9^|P?g0&8FBg^>9r{9ZIbCX<IuMjV}}
z350W3H~~goKH`KiTJpK_sGZlM9ErUXQziDbHV5M}t6%o2T~xiz(vp)e`~%lkk6ar$
zbTuqZiYAZc>zgJw>3tT7eC|@l&t7KL7)`F6lj_tuXL_~qQctuRlPz=gBj?DEqgk>D
zn@`XVN8wB_jhBCPk{(N*^f<an58sj=FtxKD2U!oYp100=Z22V|OwF{%+t41M9q=A7
zj}srD$b69bAoEekd@Kp(<Gc>@;qtKQ>SaERP?x&G%bNNK`~-)J!=7-TFE_WydfKuc
z7g<kNtjCdOJ)mFf*@-=%U+n>udyx3NdE(<LAU?YF9(WRbpbNzZPDnn0nh!D`WIigH
zk0Zf+z<eF*<0$}6rknfN+*-L2<flYXi`l$96y(Qy``qVuq&}^w51``H8TSEG0r}Cc
z`M^%}q54H1K-CAy&zmPd0P>4C)h+wLlkP*i(0%9$-G`#?gX{;{kJ24)=0W<SmBE1g
zR$n4kdY3SlgGLaf#I!tKUi@*mH{t|r(<)Js@g9(ve--mkta-&nkVWDQAfsu?Xqsjk
zvKpPNMtWB(rCQ5(C~WI@sM|#WPy7BLt3g)NA*+$zf=X?zH9XYX6!B2IlPaEScN*VE
zO$S*GvKpnVhRKLJ{B=YfuoXb3W>tsMN-+<0u$t#xQK7vVhBQbg4dM!DkfWUj@f{7)
zUeeRPL&$@W2X)AU90iNH)~cQr5%QjhPzQBAwGK5mK!pdn5ON`<T!_nXA@7yAkgEVb
zHCOit0IihwlsJm@J@1AGVS!I~JjhePgP;RF=$Rk{9VkLr<%3kH2RC&yRZt=Anh<P7
zA?QREf>W{(*7_h9LN2713waV;h|<^LLKIZsC(}-bD)l}BNU`AO-EbkS`00)eQL2Ir
z=~so|nJh#*kcF`72gy(m$PiPom{aY#5Nw4Z+KDhkPYFX<`h#Q$$&gYqROd5YmHto#
zTZFr*{b7~jAL?NB&%2~ISpK7p;vCA7q_@I4Lq>F7@8IPF$%bqs(j!x(Czj?Esn(rF
z0@S+0ub3n0d{mjGG5-R5RGFqB>er*n6h3UkdeOd|T7d&oox2?ZW-brRZU?~ZJ^{0*
z9hlvd!0aM0BQPT{_Xe0P8DQqG1k8>+Fhdt9Gi-Ba(4REJ>8u$rZANrPbnXv2J2L3(
zy%IXR3edTWycxEMGw9Ep;dJT@m^&jnBRco!qJ}8}&viwLb)`s2*B5|A>><?(&>nF;
zhYx|c%mz9FkAO`r;nZ>MwuJy)%2CTKEz)Tk$EguShQD0K(bWG(oQJSWW$H_`2=kAB
zrVBs$A=Ih;iHFLR5@qVp<CaY&P@%Q5+auKT=+GnV2`L=gbjy1)PyrP^s7uWJd=cg4
zz#BIrbh9)zZa3(GSRsiOU?Nm>1QnnLDnM&mQJQD&3LVPCVgwGc0ch#g=>=N+o)oKX
zE(j6IAObL-=nN#N8j#?6L4py}bj!z+Z9sw((}LB`IJ*}hvE2)Y;2;YQ9KoS8aF8w*
z06`8doxnhe#RS)&j4*eTJ#fJ_s70U`!0=mqpXaF&gpm>WMTGDm0T0!=hR~pMhb)uc
zL~pjPsW}T7KAHr|x*Z^NR2BuVYIvScLM@_FwNnjql=ZTbNTZ<P=~pyd?TUu0ws!B(
za%?Mj?55Ud)wo=&#U`;#k1`n91Xy|9kI?e??XSf*aU>AA`z82O8V5hhqc?H=?I<<p
zDsIZ5w|LFrjPKBZazYum`U3}_!>r@7wI2))sxu7nKx;nk$mio+Z#rJ?>axpSUL#m<
z@#5uQ?Fl(Qnvc`Ay?)F4yA&-k(whc7alUn47Iuj1i8E+DZAlT7&vsqmv?p6q@^tz&
zEby97`z59}!*Gq!y2i+FQ**Q~GO*r6yk2Ce*V!Ud?N&n~<l!oFXqB-{6&eHR-J#&P
zg2_;GwV`PQE}>iynex(NFEobLuGQ6crqH;H@@VSgk|QTGAg$?W$+6`3Fmb&)L%Aiv
z+2{<+>`G^-^=iKXGvAZYa9(+d*F}Aa+d+Ma3c2AwVeyb=Uq$GBeu#?c-1z*sn51!2
z49ag2VtQ}*33PYE&vI)}2RHnb=+Zei{A6$MhM(QsF7qyqmg9MvMgNEl!jF%7x%1;(
z#*LWig-C|9Ia&HaP)*JDZ~AF7+h$6``Oj2*Fgp^?Ohq_T{oxF|aMu1X6NxTiIAb_#
z4Ch~sKcXNi(gzXKw>M4kY$=FmraheLE}A|4!OZ#@%N%3*$BX4Nu7SxvdEL}3wSZgI
vS_I!kt>t}P_^Qt_yz+G(CajNR|1r$2FV+X*cb55!>x=&b=sGwSiOK)~C|)dV

literal 2395
zcmV-h38eNPiwFP!000001MOYgZsRx-ea}}2?pF_^A|;9%PcqnU>;elcu#KI5H)LC#
zXh)U|N$zy^VZVJy+wt92B3|6?RDc+eO&3K<JXMFMO8)Kl@6+7-mR5CE7I!@$e((4D
zo8Kl`@~ixRsFJBC8x*xVy6ZhQ&Ft6P+oz`|l0Vl;Q&uF;=A=$<|DWV}aw{9%_U>;y
zZ`;5mX%h9`>fNMis%$iGQm;s+>0NJ>jQ@P7%6T#AEnBVHjmx~Oyl+W<*Zc5w@z=Xu
znYrDubH?^8nWfdf+3BpTGufnho*gtfVMo1gwOO^QWuxNZ{=?sb56e?py|J-%>_ks?
z(oB=;AuA61snR50P6Q=_Qu;CvZ|`Dczl+>{7nS`kvU)fxtENh_=CGSlS>|a{EPHCI
zdD^|7dYt6)mN_>R=x+UM)-+|y`F~CF`ZWVszP(;OZ(WHGRW>=l5O-Rfu=12mn#bXH
zOVhQq{%pzmx2(=ad3x;Zv!XF({#nz!?scALleBKR(z|U=SbAJFyKNize!JI>VENXb
zlUj6<C(miMGXHVop1jo@uNM8*ER>`FrsHNcyg!<xm?YK2`^EcMe(!CZtKajo$zAW?
z{_gbb4@er5;BzoPvvPeMX`k*7_wYKNGCdmYTdw4}C&fdauI>^Nhkf-j5X2Arp?vAq
zTbifS;kc}dLkDYOFbngGHG4Rqm-WguOh2aC!((&WHtS}4R92I;YCCbCKsWRCWBD{Z
z5>vJNuDA5EysE=0nPl_&+$h>6Y5C@I{k&p9{VOZdBP$AYSCqWXEv~45uzo<|K}e#0
z)b+xS%c2;j#bj~TuO7>>kE3oUP|T;}*?zyre9K#m%IGI;Uke=(qHdC^875U#KJ8mi
z<!H2)@s{mjo)!=12N3CZ(mF{U`;fPkr72olwl_hWE=*02T4r+fN_eUFjBP&g9wi{D
zI6&f0Q!YHZxA}C(>zw{BtiH>3zYB+f%-#vT5i-A|-<u<lN%bL<k;o=$QWAj(WG?_=
zNCy$20=PVk)nT`O8#NaPmu5FQ-D`7lWmfyVZEsiLb5*Lqa+;jj95@r;pQ3YR(H!eh
zy}xSmshn4t47YA|`Z)-Ej;<%6*U9e9^_m;3OD~H}q+|VT?=Ja^KfR75jejVn>G2D+
zK~i{SFGo3ynGotYCt>=WB(lv(_?nY|Z=IAxNJ@~DXpxdY-@}4$nU%yVRsz%kEdl>L
zF9C|g1c?a}6NAKrX%G{B8DbLZ!=|uHOacNC6|$ElF$syF5tWBmLQKAV`izvMD<u&~
zNnBA9u1`t8zD}|cO2EES0w|RrE74;mkpWg>TPuMVu>@SGCD0<50O}=3OOTeBq$ON~
zmc*B#CBgu1GTXc)fRL(g6fuzi8j3)uLq$w}d|vWTq$Qnc37}NsjF-d)c!_nb1U6y`
zwJ(+cswK!vG*h^IeFsZz%O&ulmrxga32o6!DC#9hOputEBqs4mVq%qCfPMlifj$Vr
z1P6;4$cWE<p|)kB5cnV>z+$RUk;%g!pJDvHc}%6#Yi=f0Ca(d~jgEBV*u937!y@GX
z?QBhIw`PQHibklLsu3(3LC&GgIrOt0?G}#Em&y_9rgVh1)Q(Ur9zo85oWm^Vkj}lk
z8Uo>E<PZo9K&R~j5=uDVsvx0QLh{a-3dI@{mn<bTz)~XXEQN1aiv2ngEF?jiqD@n{
z0bgsil!U(2l2Av*B($xXgkm`fQWc~srm0G(Lsi6us7ho2J}sA&NB{-8RZ~K-sN_A7
z6s#(7M^c0Vk^&C2lr1p@9H=Q+T7o=9m#4%gc#3sB1=fNJI8jufO;W)E6C^4~RLl|;
zp+QtAT<DQpz6tzf)|m?9TU90$%S_%8QNcPBcT9zX38rFSPk}8#g*p&au-F8diY8N`
z)PSd@))f_4ODfcfq(a*y6|6Wxrh-hxC{x)d8?H)DsDa#9Cp9OO5g)dSPAFELyi@jp
zWhd4c$f-C<JIhn_8L_z?5s^3w`)nWsBwq$7f#o1+Z#YN!N#_AyFiPr5+7{O9<~dJK
zhX8@a2n<|AV4;HuEVLGZf&B<9v>t(l?tZ)>cvDWxUhY0K9lf0b=1?D)g#%y~FTfmI
z2WHU<%mRTKff<4MYJi#P0CRXDVCMS33@$=uSjWs@KWK*bs2MP9Ms!AWz8-YuI_NAe
zgwBxxbaoLp!#Z#V`;jxWht7bpGomx1^Yx%}tbxw^k`!|#Nol9%L)d3FpRDSWD4?QG
z3FAQo1BeL?BemlT>iEZ(qGnaul;bkbOK*~S$!wNq<K%zxBBU-=sV~_yt$+DXIZcY6
zLYdmV>rjz0qDY;>h}Zx|2)h_TDX51vtuZ2s1XGoL*MSjVs-&J~wVHPClU%e_nR}mC
zxPd64g%Sc$!VO9=-vCO0)lh;G${1JAN>Dg4P}wb<2aB|Nd3*(F^hLACYC&u;gAITo
zge!0W6X0MqhF~NNgGGJf5*#=Qf{>|QnCk$Cmy|ce1U*c^fWb5-d@l3n6Pv?KyC@*)
znt%2xRNzEC%`T3kFc?sY5Pg*yOQVia%1lnguyu2IXGF(7rtJLAF^PT77ia3XG-X{U
z@A8|$S6^dr-J8MeJ!}RWihY=Y*oOvoiBTv*P>}ILi~<PazIsB^Rm493$mexkdXqHs
zCP|ZF2&5GP(EvjrH@W^yJJ%mN*9X1|8RQKY$r}O)9e{dVnkq*m!m>KPJEkL_2Ul4X
zX;GPt?R#Tk-5U!x-Z(Vyqq0_i?n(F&7kz)>ihVxd1Om!vAFf5r_>^Z7lHL2@k7Yjj
zS$<j;9k8Q)Nh6PWwp)oC1%hwjfO6?cqzAkjIQS#299Q7}WN<(c58MUhk$ynVt;XXj
zQ#Dkt17M3}RjyvGN96o$K+d`j`bW-GHRNFoB-qJw<-D(epEA1=Sj>dFy*MlcFo*))
zj|hb;*aE7{@t<jPgIhm3TR+EdG;}#uU5<WsU1ZhgsAtWsoequNIi2Xd*P$_bol{;X
zFp-Q!Z4w*xto0bEdV1kfa}dP$g;0Bq*P%Hq67m-*o2mCTtFv)}zDG}XK$hdk<plcK
zSlq7eAVZP0@W6a$!UJzn9+>~0l!w<9&c!a0C4_@yiMQ$x%i}zGPOJNy<$?THKOTC2
N^B1u0#l_>d003*Jdy)VE

diff --git a/network.tex b/network.tex
index d564dc4..2427690 100644
--- a/network.tex
+++ b/network.tex
@@ -93,18 +93,18 @@ quello di non avere nessun programma che svolga un ruolo preminente.
 Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
 in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
 ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
-la separazione netta dei compiti che si ritrova nelle archietetture
+la separazione netta dei compiti che si ritrova nelle architetture
 \textit{client-server}.
 
 Le architetture \textit{peer-to-peer} sono salite alla ribalta con
 l'esplosione del fenomeno Napster, ma gli stessi protocolli di routing sono un
-buon esempio di archietetture \textit{peer-to-peer}, in cui ciascun nodo,
+buon esempio di architetture \textit{peer-to-peer}, in cui ciascun nodo,
 tramite il demone che gestisce il routing, richiede ed invia informazioni ad
 altri nodi.
 
-In realtà in molti casi di archietture classificate come \textit{peer-to-peer}
+In realtà in molti casi di architetture classificate come \textit{peer-to-peer}
 non è detto che la struttura sia totalmente paritetica e ci sono parecchi
-esempi in cui alcuni servizi vengono centralizzati o disribuiti
+esempi in cui alcuni servizi vengono centralizzati o distribuiti
 gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
 effettuate su un server centrale.
 
@@ -130,24 +130,31 @@ scalabilit
 Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
 talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
 carico delle richieste su più server identici, mantenendo quindi
-sostanzialmente inalterata l'archiettettura \textit{client-server} originale.
+sostanzialmente inalterata l'architettura \textit{client-server} originale.
 
 Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
 servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
-inefficienza dell'uso delle risorse. Il problema è particolarmente grave per i
-database che non possono essere replicati e sincronizzati facilemente, e che
-sono molto onerosi sia in termini di richiesta risorse.
+inefficienza dell'uso delle risorse. Il problema è particolarmente grave ad
+esempio per i database che non possono essere replicati e sincronizzati
+facilmente, e che sono molto onerosi, la loro replicazione è costosa e
+complessa.
 
 È a partire da queste problematiche che nasce il modello \textit{three-tier},
-che si struttura, come dice il nome, su tre livelli. Il primo, quello dei
-client, che eseguono le richieste e gestiscono l'interfaccia con l'utente,
+che si struttura, come dice il nome, su tre livelli. Il primo livello, quello
+dei client che eseguono le richieste e gestiscono l'interfaccia con l'utente,
 resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
 parte server viene suddivisa in due livelli, introducendo un
 \textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
-richieste dei client per ottimizzare l'accesso al terzo livello, quello dei
-server che invece si limita a fornire dei dati che verranno usati dal
-\textit{middle-tier} per eseguire le operazioni.
+richieste dei client per ottimizzare l'accesso al terzo livello, che è quello
+che si limita a fornire i dati dinamici che verranno usati dalla logica
+implementata nel \textit{middle-tier} per eseguire le operazioni richieste dai
+client.
 
+In questo modo si può disaccoppiare la logica dai dati, replicando la prima,
+che è molto meno soggetta a cambiamenti ed evoluzione, e non soffre di
+problemi di sincronizzazione, e centralizzando opportunamente i secondi. In
+questo modo si può distribuire il carico ed accedere in maniera efficiente i
+dati.
 
 
 \section{I protocolli di rete}
@@ -201,14 +208,6 @@ de facto.  Il modello di quest'ultimo viene chiamato anche modello DoD (sigla
 che sta per \textit{Department of Defense}), dato che fu sviluppato
 dall'agenzia ARPA per il Dipartimento della Difesa Americano.
 
-\begin{figure}[!htbp]
-  \centering
-  \includegraphics[width=12cm]{img/iso_tcp_comp}
-  \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la  
-    relative corrispondenze e la divisione fra kernel e user space.}
-  \label{fig:net_osi_tcpip_comp}
-\end{figure}
-
 
 \subsection{Il modello TCP/IP (o DoD)}
 \label{sec:net_tcpip_overview}
@@ -218,7 +217,9 @@ Cos
 \figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
 fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
 ad inserirsi all'interno di un sistema rispetto alla divisione fra user space
-e kernel space spiegata in \secref{sec:intro_unix_struct}.
+e kernel space spiegata in \secref{sec:intro_unix_struct}.\footnote{in realtà
+  è possibile accedere, attraverso una opportuna interfaccia (come vedremo in
+  \secref{sec:sock_sa_packet}), anche ai livelli inferiori.}
 
 \begin{table}[htb]
   \centering
@@ -245,27 +246,34 @@ principali protocolli che lo compongono, il TCP (\textit{Trasmission Control
   Protocol}) che copre il livello 3 e l'IP (\textit{Internet Protocol}) che
 copre il livello 2. Le funzioni dei vari livelli sono le seguenti:
 
-\begin{description}
-\item \textbf{Applicazione} É relativo ai programmi di interfaccia con la
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
+\item[\textbf{Applicazione}] É relativo ai programmi di interfaccia con la
   rete, in genere questi vengono realizzati secondo il modello client-server
   (vedi \secref{sec:net_cliserv}), realizzando una comunicazione secondo un
   protocollo che è specifico di ciascuna applicazione.
-\item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
+\item[\textbf{Trasporto}] Fornisce la comunicazione tra le due stazioni
   terminali su cui girano gli applicativi, regola il flusso delle
   informazioni, può fornire un trasporto affidabile, cioè con recupero degli
   errori o inaffidabile. I protocolli principali di questo livello sono il TCP
   e l'UDP.
-\item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
+\item[\textbf{Rete}] Si occupa dello smistamento dei singoli pacchetti su una
   rete complessa e interconnessa, a questo stesso livello operano i protocolli
   per il reperimento delle informazioni necessarie allo smistamento, per lo
   scambio di messaggi di controllo e per il monitoraggio della rete. Il
   protocollo su cui si basa questo livello è IP (sia nella attuale versione,
-  IPv4 che nella nuova IPv6).
-\item \textbf{Connessione} È responsabile per l'interfacciamento al
+  IPv4, che nella nuova versione, IPv6).
+\item[\textbf{Connessione}] È responsabile per l'interfacciamento al
   dispositivo elettronico che effettua la comunicazione fisica, gestendo
-  l'invio e la ricezione dall'hardware dei pacchetti.
-\end{description}
+  l'invio e la ricezione dei pacchetti da e verso l'hardware.
+\end{basedescript}
 
+\begin{figure}[!htb]
+  \centering
+  \includegraphics[width=13cm]{img/iso_tcp_comp}
+  \caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la  
+    relative corrispondenze e la divisione fra kernel e user space.}
+  \label{fig:net_osi_tcpip_comp}
+\end{figure}
 
 La comunicazione fra due stazioni remote avviene secondo le modalità
 illustrate in \figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso
@@ -274,25 +282,32 @@ livello. Si 
 se in realtà i protocolli di trasmissione usati possono essere molti altri.
 
 \begin{figure}[!htb]
-  \centering \includegraphics[width=10cm]{img/tcp_data_flux}
+  \centering \includegraphics[width=12cm]{img/tcp_data_flux}
   \caption{Strutturazione del flusso dei dati nella comunicazione fra due
     applicazioni attraverso i protocolli della suite TCP/IP.}
   \label{fig:net_tcpip_data_flux}
 \end{figure}
 
-La struttura della comunicazione attraverso il TCP/IP si può pertanto
-riassumere nei seguenti passi:
+Per chiarire meglio la struttura della comunicazione attraverso i vari
+protocolli mostrata in \figref{fig:net_tcpip_data_flux}, conviene prendere in
+esame i singoli passaggi fatti per passare da un livello al sottostante,
+la procedura si può riassumere nei seguenti passi:
 \begin{itemize}
-\item Le singole applicazioni si scambieranno i dati secondo un loro formato
-  specifico, implementando un protocollo di applicazione (esempi possono
-  essere HTTP, POP, telnet, SMTP, etc).
-\item Questi dati vengono inviati al livello di trasporto usando
+\item Le singole applicazioni comunicano scambiandosi i dati ciascuna secondo
+  un suo specifico formato. Per applicazioni generiche, come la posta o le
+  pagine web, viene di solito definito ed implementato quello che viene
+  chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
+  SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
+  solito attraverso un RFC\footnote{L'acronimo RFC sta per \textit{Request For
+      Comment} ed è la procedura attraverso la quale vengono proposti gli
+    standard per Internet.}).
+\item I dati delle applicazioni vengono inviati al livello di trasporto usando
   un'interfaccia opportuna (i \textit{socket}\index{socket}, che esamineremo
-  in dettaglio in seguito). Qui verranno spezzati in pacchetti di dimensione
-  opportuna e incapsulati nel protocollo di trasporto, aggiungendo ad ogni
-  pacchetto le informazioni necessarie per la sua gestione. Questo processo
-  viene svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
-  protocollo di trasporto sia questo.
+  in dettaglio in \capref{cha:socket_intro}). Qui verranno spezzati in
+  pacchetti di dimensione opportuna e incapsulati nel protocollo di trasporto,
+  aggiungendo ad ogni pacchetto le informazioni necessarie per la sua
+  gestione. Questo processo viene svolto direttamente nel kernel, ad esempio
+  dallo stack TCP, nel caso il protocollo di trasporto usato sia questo.
 \item Una volta composto il pacchetto nel formato adatto al protocollo di
   trasporto usato questo sarà passato al successivo livello, quello di rete,
   che si occupa di inserire le opportune informazioni per poter effettuare
@@ -300,9 +315,12 @@ riassumere nei seguenti passi:
   genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
   i numeri IP che identificano i computer su internet.
 \item L'ultimo passo è il trasferimento del pacchetto al driver della
-  interfaccia di trasmissione che si incarica di incapsularlo nel relativo
-  protocollo di trasmissione fisica usato dall'hardware usato per la
-  comunicazione (ad esempio \textit{ethernet} per una scheda di rete).
+  interfaccia di trasmissione, che si incarica di incapsularlo nel relativo
+  protocollo di trasmissione. Questo può avvenire sia in maniera diretta, come
+  nel caso di ethernet, in cui i pacchetti vengono inviati sulla linea
+  attraverso le schede di rete, che in maniera indiretta con protocolli come
+  PPP o SLIP, che vengono usati come interfaccia per far passare i dati su
+  altri dispositivi di comunicazione (come la seriale o la parallela).
 \end{itemize}
 
 
@@ -322,13 +340,13 @@ successo n
 È il livello di trasporto che si deve occupare (qualora necessiti) del
 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
-al livello di trasporto o superiore.
+al livello di trasporto o ai livelli superiori.
 
 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
-terminali di comunicazione, ma possono anche assumere il ruolo di router, per
-l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
-flessibilità della rete che è in grado di adattarsi ai mutamenti delle
-interconnessioni.
+terminali di comunicazione, ma possono anche assumere il ruolo di
+\textit{router} (\textsl{instradatori}), per l'interscambio di pacchetti da
+una rete ad un'altra. Questo rende possibile la flessibilità della rete che è
+in grado di adattarsi ai mutamenti delle interconnessioni.
 
 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
@@ -343,39 +361,38 @@ questo poi sar
 \section{Il protocollo TCP/IP}
 \label{sec:net_tpcip}
 
-Come appena mostrato il protocollo TCP/IP è un insieme di protocolli diversi,
-che operano su 4 livelli diversi. Per gli interessi della programmazione di
-rete però sono importanti principalmente i due livelli centrali, e soprattutto
-quello di trasporto. 
+Come accennato in \secref{sec:net_protocols} il protocollo TCP/IP è un insieme
+di protocolli diversi, che operano su 4 livelli diversi. Per gli interessi
+della programmazione di rete però sono importanti principalmente i due livelli
+centrali, e soprattutto quello di trasporto.
 
-La principale interfaccia di programmazione di rete, quella dei
+La principale interfaccia usata nella programmazione di rete, quella dei
 socket\index{socket}, è infatti un'interfaccia nei confronti di quest'ultimo.
 Questo avviene perché al di sopra del livello di trasporto i programmi hanno a
 che fare solo con dettagli specifici delle applicazioni, mentre al di sotto
 vengono curati tutti i dettagli relativi alla comunicazione. È pertanto
-naturale definire una interfaccia di programmazione su questo confine tanto
+naturale definire una interfaccia di programmazione su questo confine, tanto
 più che è proprio lì (come evidenziato in \figref{fig:net_osi_tcpip_comp}) che
 nei sistemi Unix (e non solo) viene inserita la divisione fra kernel space e
 user space.
 
 In realtà in un sistema Unix è possibile accedere anche agli altri livelli
-inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
-è indicata in \figref{fig:net_osi_tcpip_comp} lasciando uno spazio fra UDP e
-TCP), ma queste vengono usate solo quando si vogliono fare applicazioni di
-sistema per il controllo della rete a basso livello, un uso quindi molto
-specialistico, e che non rientra in quanto trattato qui.
+inferiori (e non solo a quello di trasporto) con opportune interfacce di
+programmazione (vedi \secref{sec:sock_sa_packet}), ma queste vengono usate
+solo quando si debbano fare applicazioni di sistema per il controllo della
+rete a basso livello, di uso quindi molto specialistico.
 
-In questa sezione daremo una breve descrizione dei vari protocolli del TCP/IP,
-concentrandoci, per le ragioni esposte sul livello di trasporto. All'interno
-di questo privilegeremo poi il protocollo TCP, per il ruolo centrale che
-svolge nella maggior parte delle applicazioni.
+In questa sezione daremo una descrizione sommaria dei vari protocolli del
+TCP/IP, concentrandoci, per le ragioni appena esposte, sul livello di
+trasporto.  All'interno di quest'ultimo privilegeremo poi il protocollo TCP,
+per il ruolo centrale che svolge nella maggior parte delle applicazioni.
 
 
 \subsection{Il quadro generale}
 \label{sec:net_tcpip_general}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
-altri membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
+molti membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
 mostra un panorama sui vari protocolli della famiglia, e delle loro relazioni
 reciproche e con alcune dalle principali applicazioni che li usano.
 
@@ -386,54 +403,89 @@ reciproche e con alcune dalle principali applicazioni che li usano.
   \label{fig:net_tcpip_overview}
 \end{figure}
 
-I vari protocolli mostrati in figura sono i seguenti:
+I vari protocolli riportati in \figref{fig:net_tcpip_overview} sono i
+seguenti:
 
-\begin{list}{}{}
-\item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
+\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
+\item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
   comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
-  cui è costruita internet. Usa indirizzi a 32 bit e provvede la trasmissione
-  dei pacchetti TCP, UDP, ICMP e IGMP.
-\item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
-  metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
-  lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
-\item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
-  orientato alla connessione che provvede un trasporto affidabile e
-  bidirezionale di un flusso di dati. I socket\index{socket} TCP sono esempi
-  di \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
-  trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È
-  usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
-  che con IPv6.
-\item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
-  connessione, a pacchetti. I socket\index{socket} UDP sono esempi di
-  \textit{datagram socket}. Contrariamente al TCP il protocollo non è
-  affidabile e non c'è garanzia che i pacchetti raggiungano la loro
-  destinazione, si perdano o vengano duplicati, o abbiano un particolare
-  ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
-\item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
-  errori e trasporta l'informazione di controllo fra stazioni remote e
-  instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
-  generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
-  se ICMP può venire usato direttamente da alcuni programmi come
-  \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
-  da ICMPv6.
-\item \textsl{IGMP} \textit{Internet Group Management Protocol}. É un
-  protocollo usato per il \textit{multicasting} (vedi
-  \secref{sec:xxx_multicast}), che è opzionale in IPv4.
-\item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
-  mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
-  internet). È usato in reti di tipo broadcast come Ethernet, Token Ring o
-  FDDI ma non serve in connessioni punto-punto.
-\item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
-  protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
-  volte per durante il boot per assegnare un indirizzo IP ad una macchina.
-\item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
+  cui è costruita internet. Usa indirizzi a 32 bit, e mantiene tutte le
+  informazioni di instradamento e controllo per la trasmissione dei pacchetti
+  sulla rete; tutti gli altri protocolli della suite (eccetto ARP e RARP, e
+  quelli specifici di IPv6) vengono trasmessi attraverso di esso.
+\item[\textsl{IPv6}] \textit{Internet Protocol version 6}. È stato progettato
+  a metà degli anni '90 per rimpiazzare IPv4. Ha uno spazio di indirizzi
+  ampliato 128 bit che consente più gerarchie di indirizzi,
+  l'autoconfigurazione, ed un nuovo tipo di indirizzi, gli \textit{anycast},
+  che consentono di inviare un pacchetto ad una stazione su un certo gruppo.
+  Effettua lo stesso servizio di trasmissione dei pacchetti di IPv4 di cui
+  vuole essere un sostituto.
+\item[\textsl{TCP}] \textit{Trasmission Control Protocol}. È un protocollo
+  orientato alla connessione che provvede un trasporto affidabile per un
+  flusso di dati bidirezionale fra due stazioni remote. Il protocollo ha cura
+  di tutti gli aspetti del trasporto, come l'acknoweledgment, i timeout, la
+  ritrasmissione, etc. È usato dalla maggior parte delle applicazioni.
+\item[\textsl{UDP}] \textit{User Datagram Protocol}. È un protocollo senza
+  connessione, per l'invio di dati a pacchetti. Contrariamente al TCP il
+  protocollo non è affidabile e non c'è garanzia che i pacchetti raggiungano
+  la loro destinazione, si perdano, vengano duplicati, o abbiano un
+  particolare ordine di arrivo.
+\item[\textsl{ICMP}] \textit{Internet Control Message Protocol}. È il
+  protocollo usato a livello 2 per gestire gli errori e trasportare le
+  informazioni di controllo fra stazioni remote e instradatori (cioè fra
+  \textit{host} e \textit{router}). I messaggi sono normalmente generati dal
+  software del kernel che gestisce la comunicazione TCP/IP, anche se ICMP può
+  venire usato direttamente da alcuni programmi come \cmd{ping}. A volte ci
+  si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
+\item[\textsl{IGMP}] \textit{Internet Group Management Protocol}. É un
+  protocollo di livello 2 usato per il \textit{multicasting} (vedi
+  \secref{sec:xxx_multicast}).  Permette alle stazioni remote di notificare ai
+  router che supportano questa comunicazione a quale gruppo esse appartengono.
+  Come ICMP viene implementato direttamente sopra IP.
+\item[\textsl{ARP}] \textit{Address Resolution Protocol}. È il protocollo che
+  mappa un indirizzo IP in un indirizzo hardware sulla rete locale. È usato in
+  reti di tipo broadcast come Ethernet, Token Ring o FDDI che hanno associato
+  un indirizzo fisico (il \textit{MAC address}) alla interfaccia, ma non serve
+  in connessioni punto-punto.
+\item[\textsl{RARP}] \textit{Reverse Address Resolution Protocol}. È il
+  protocollo che esegue l'operazione inversa rispetto ad ARP (da cui il nome)
+  mappando un indirizzo hardware in un indirizzo IP. Viene usato a volte per
+  durante l'avvio per assegnare un indirizzo IP ad una macchina.
+\item[\textsl{ICMPv6}] \textit{Internet Control Message Protocol, version 6}.
   Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
-\item \textsl{NETLINK} \textit{Netlink}.  Provvede, in Linux, l'interfaccia di
-  accesso alla comunicazione a basso livello.
-\end{list}
+\item[\textsl{EGP}] \textit{Exterior Gateway Protocol}. È un protocollo di
+  routing usato per comunicare lo stato fra gateway vicini a livello di
+  \textsl{sistemi autonomi}\footnote{vengono chiamati \textit{autonomous
+      systems} i raggruppamenti al livello più alto della rete.}, con
+  meccanismi che permettono di identificare i vicini, controllarne la
+  raggiungibilità e scambiare informazioni sullo stato della rete. Viene
+  implementato direttamente sopra IP. 
+\item[\textsl{OSPF}] \textit{Open Shortest Path First}. È in protocollo di
+  routing per router su reti interne, che permette a questi ultimi di
+  scambiarsi informazioni sullo stato delle connessioni e dei legami che
+  ciascuno ha con gli altri. Viene implementato direttamente sopra IP.
+\item[\textsl{GRE}] \textit{Generic Routing Encapsulation}. È un protocollo
+  generico di incapsulamento che permette di incapsulare un qualunque altro
+  protocollo all'interno di IP. 
+\item[\textsl{AH}] \textit{Authentication Header}. Provvede l'autenticazione
+  dell'integrità e dell'origine di un pacchetto. È una opzione nativa in IPv6
+  e viene implementato come protocollo a sé su IPv4. Fa parte della suite di
+  IPSEC che provvede la trasmissione cifrata ed autenticata a livello IP.
+\item[\textsl{ESP}] \textit{Encapsulating Security Payload}. Provvede la
+  cifratura insieme all'autenticazione dell'integrità e dell'origine di un
+  pacchetto. Come per AH è opzione nativa in IPv6 e viene implementato come
+  protocollo a sé su IPv4.
+\item[\textsl{PPP}] \textit{Point-to-Point Protocol}. È un protocollo a
+  livello 1 progettato per lo scambio di pacchetti su connessioni punto punto.
+  Viene usato per configurare i collegamenti, definire i protocolli di rete
+  usati ed incapsulare i pacchetti di dati. È un protocollo complesso con
+  varie componenti.
+\item[\textsl{SLIP}] \textit{Serial Line over IP}. È un protocollo di livello
+  1 che permette di trasmettere un pacchetto IP attraverso una linea seriale.
+\end{basedescript}
 
 Gran parte delle applicazioni comunicano usando TCP o UDP, solo alcune, e per
-scopi particolari si rifanno dirattamente ad IP (ed i suoi correlati ICMP e
+scopi particolari si rifanno direttamente ad IP (ed i suoi correlati ICMP e
 IGMP); benché sia TCP che UDP siano basati su IP e sia possibile intervenire a
 questo livello con i \textit{raw socket} questa tecnica è molto meno diffusa e
 a parte applicazioni particolari si preferisce sempre usare i servizi messi a
@@ -550,9 +602,9 @@ quelle che usano il multicasting.
 \label{sec:net_tcp}
 
 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
-diverso da UDP; alla base del suo design infatti non stanno semplicità e
-velocità, ma la ricerca della massima affidabilità possibile nella
-trasmissione dei dati.
+diverso da UDP; alla base della sua progettazione infatti non stanno
+semplicità e velocità, ma la ricerca della massima affidabilità possibile
+nella trasmissione dei dati.
 
 La prima differenza con UDP è che TCP provvede sempre una connessione diretta
 fra un client e un server, attraverso la quale essi possono comunicare; per
@@ -566,16 +618,16 @@ inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}''
 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
 ritrasmessi per un determinato numero di tentativi, intervallati da un periodo
 di tempo crescente, fino a che sarà considerata fallita o caduta la
-connessione (e generato un errore di \textit{time-out}), dopo un periodo di
-tempo che dipende dall'implementazione e che può variare far i quattro e i
-dieci minuti.
+connessione (e sarà generato un errore di \textit{timeout}); il periodo di
+tempo dipende dall'implementazione e può variare far i quattro e i dieci
+minuti.
 
-Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
-di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
-tempo di andata e ritorno dei pacchetti (il cosiddetto RTT, 
-\textit{round-trip time}) fra un client e un server che lo rende in grado di
-adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
-cadere facilmente in timeout.
+Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
+linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
+del tempo di andata e ritorno dei pacchetti fra un client e un server (il
+cosiddetto RTT, \textit{round-trip time}), che lo rende in grado di adattarsi
+alle condizioni della rete per non generare inutili ritrasmissioni o cadere
+facilmente in timeout.
 
 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
@@ -584,8 +636,9 @@ protocollo in due segmenti (le unit
 chiamate \textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
-più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
-all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
+più volte a causa di ritrasmissioni dovute alla perdita degli
+\textit{acknowlegment}, all'arrivo sarà comunque possibile riordinare i dati e
+scartare i duplicati.
 
 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
 cioè specifica sempre all'altro capo della trasmissione quanti dati può
@@ -598,17 +651,17 @@ Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
 socket\index{socket} ed aumentando con la lettura di quest'ultimo da parte
 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
 verranno accettati altri dati.  Si noti che UDP non provvede niente di tutto
-ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
+ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un ritmo che il
 ricevente non può sostenere.
 
-Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
-\textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
-stesso tempo, il che poi comporta che quanto dicevamo a proposito del
-controllo di flusso e della gestione della sequenzialità dei dati viene
+Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese si
+dice che è \textit{full-duplex}). È cioè possibile sia trasmettere che
+ricevere allo stesso tempo, il che comporta che quanto dicevamo a proposito
+del controllo di flusso e della gestione della sequenzialità dei dati viene
 effettuato per entrambe le direzioni di comunicazione.
 
-Una descrizione più accurata del protocollo è fornita in appendice
-\capref{cha:tcp_protocol}.
+%% Una descrizione più accurata del protocollo è fornita in appendice
+%% \capref{cha:tcp_protocol}.
 
 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
 \label{sec:net_lim_dim}
@@ -622,9 +675,9 @@ possono avere delle conseguenze sul comportamento delle applicazioni.
 Un elenco di questi limiti, insieme ad un breve accenno alle loro origini ed
 alle eventuali implicazioni che possono avere, è il seguente:
 \begin{itemize}
-\item La dimensione massima di un pacchetto IP è di 65535 byte, compreso
-  l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
-  apposito nell'header di IP che è lungo 16 bit (vedi
+\item La dimensione massima di un pacchetto IP è di 65535 byte, compresa
+  l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
+  campo apposito nell'header di IP che è lungo 16 bit (vedi
   \figref{fig:IP_ipv4_head}).
 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
   il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
@@ -632,18 +685,18 @@ alle eventuali implicazioni che possono avere, 
   suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
   un pacchetto usando la \textit{jumbo payload option}.
 \item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
-  dipende dal protocollo specifico usato al livello di link. Il più comune è
-  quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
-  sono riportati in \tabref{tab:net_mtu_values}.
+  dipende dal protocollo specifico usato al livello di connessione fisica. Il
+  più comune è quello di ethernet che è pari a 1500 byte, una serie di altri
+  valori possibili sono riportati in \tabref{tab:net_mtu_values}.
 \end{itemize}
 
 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
 dimensioni eccedono la MTU viene eseguita la cosiddetta
-\textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
-IPv6, anche se i pacchetti frammentati sono gestiti con modalità
-diverse,\footnote{il primo usa un flag nell'header, il secondo una opportuna
-  opzione, si veda \secref{cha:ip_protocol}.}) in blocchi più piccoli che
-possono essere trasmessi attraverso l'interfaccia.
+\textit{frammentazione}, i pacchetti cioè vengono suddivisi\footnote{questo
+  accade sia per IPv4 che per IPv6, anche se i pacchetti frammentati sono
+  gestiti con modalità diverse, IPv4 usa un flag nell'header, IPv6 una
+  opportuna opzione, si veda \secref{cha:ip_protocol}.}) in blocchi più
+piccoli che possono essere trasmessi attraverso l'interfaccia.
 
 \begin{table}[!htb]
   \centering
@@ -674,7 +727,7 @@ sensi, con diverse tipologie di rete coinvolte.
 
 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
-frammentano i pacchetti che trasmettono (anche se possono frammentare i
+frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
 pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
 volta frammentati i pacchetti possono essere riassemblati solo alla
 destinazione.
@@ -683,28 +736,30 @@ Nell'header di IPv4 
 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
 cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
 messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
-  fragmentation needed but DF bit set}.
-
-Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
-di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
-un messaggio di errore ICMPv6 di tipo \textit{packet too big}.
-
-Dato che il meccanismo di frammentazione e riassemblaggio comporta
-inefficienza, normalmente viene utilizzato il procedimento della \textit{path
-  MTU discover} (vedi RFC~1191 per IPv4 e RFC~1981 per IPv6) che permette di
-trovare il \textit{path MTU} fra due stazioni; per la realizzazione del
-procedimento si usa il flag DF di IPv4 e il comportamento normale di IPv6
-inviando delle opportune serie di pacchetti (per i dettagli vedere l'RFC~1191
-per IPv4 e l'RFC~1981 per IPv6) fintanto che non si hanno più errori. 
+  fragmentation needed but DF bit set}.  Dato che i router IPv6 non possono
+effettuare la frammentazione la ricezione di un pacchetto di dimensione
+eccessiva per la ritrasmissione genererà sempre un messaggio di errore ICMPv6
+di tipo \textit{packet too big}.
+
+Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
+comporta inefficienza, normalmente viene utilizzato un procedimento, detto
+\textit{path MTU discovery} che permette di determinare il \textit{path MTU}
+fra due stazioni; per la realizzazione del procedimento si usa il flag DF di
+IPv4 e il comportamento normale di IPv6 inviando delle opportune serie di
+pacchetti (per i dettagli vedere l'RFC~1191 per IPv4 e l'RFC~1981 per IPv6)
+fintanto che non si hanno più errori.
 
 Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 è
 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
-conoscere il \textit{path MTU}.
-
+conoscere da subito il \textit{path MTU}.
 
 Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
-all'altro capo la dimensione massima del segmento di dati.
+all'altro capo della connessione la dimensione massima dimensione del segmento
+di dati che può essere ricevuto, così da evitare la frammentazione. Di norma
+viene impostato alla dimensione della MTU dell'interfaccia meno la lunghezza
+delle intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
+\const{TCP\_MSS} è 512.
 
 
 %\subsection{Il passaggio dei dati in TCP}
diff --git a/socket.tex b/socket.tex
index 2dc5674..37bc642 100644
--- a/socket.tex
+++ b/socket.tex
@@ -34,10 +34,10 @@ con essi.
 \label{sec:sock_socket_def}
 
 I \textit{socket}\footnote{una traduzione letterale potrebbe essere
-  \textsl{presa}, ma essendo universalmente noti come socket utilizzeremo
-  sempre la parola inglese.} sono uno dei principali meccanismi di
-comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati in
-\secref{sec:ipc_socketpair}, fra i vari meccanismi di intercominazione fra
+  \textsl{presa}, ma essendo universalmente noti come \textit{socket}
+  utilizzeremo sempre la parola inglese.} sono uno dei principali meccanismi
+di comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati
+in \secref{sec:ipc_socketpair}, fra i vari meccanismi di intercominazione fra
 processi. Un socket costituisce in sostanza un canale di comunicazione fra due
 processi su cui si possono leggere e scrivere dati analogo a quello di una
 pipe (vedi \secref{sec:ipc_pipes}) ma, a differenza di questa e degli altri
@@ -55,7 +55,7 @@ di quella dei socket (n
 
 La flessibilità e la genericità dell'interfaccia inoltre consente di
 utilizzare i socket con i più disparati meccanismi di comunicazione, e non
-solo con la suite dei protocolli TCP/IP, anche se questa sarà comunque quella
+solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
 di cui tratteremo in maniera più estesa.
 
 
@@ -78,8 +78,10 @@ funzioni utilizzate.
 
 La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
 comunicazione che si vuole effettuare. Ad esempio alcuni stili di
-comunicazione considerano i dati come una sequenza continua di byte, altri
-invece li raggruppano in blocchi (i pacchetti).
+comunicazione considerano i dati come una sequenza continua di byte, in quello
+che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
+altri invece li raggruppano in \textsl{pacchetti} (in inglese
+\textit{datagram}) che vengono inviati in blocchi separati.
 
 Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
 meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
@@ -95,7 +97,8 @@ chiunque si collega possa riceverli.
 
 É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
 la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
-gestire la perdita o il rimescolamento dei dati.
+gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
+dovranno essere opportunamente trattati, ecc.
 
 
 \section{La creazione di un \textit{socket}}
@@ -110,7 +113,7 @@ il tipo di comunicazione che esso deve utilizzare.
 \label{sec:sock_socket}
 
 La creazione di un socket avviene attraverso l'uso della funzione
-\funcd{socket}; questa restituisce un \textit{file descriptor}\footnote{del
+\funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
   tutto analogo a quelli che si ottengono per i file di dati e le pipe,
   descritti in \secref{sec:file_fd}.} che serve come riferimento al socket; il
 suo prototipo è:
@@ -132,16 +135,18 @@ suo prototipo 
   \item[\errcode{EINVAL}] Protocollo sconosciuto o dominio non disponibile.
   \item[\errcode{ENOBUFS}] Non c'è sufficiente memoria per creare il socket
     (può essere anche \errval{ENOMEM}).
-  \end{errlist}}
+  \end{errlist}
+  inoltre, a seconda del protocollo usato, potranno essere generati altri
+  errori, che sono riportati nelle relative pagine di manuale.}
 \end{prototype}
 
 La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
-(definisce cioè la famiglia di protocolli, come vedremo in
-\secref{sec:sock_domain}), \param{type} specifica il tipo di socket (definisce
-cioè lo stile di comunicazione, come vedremo in \secref{sec:sock_type}) e
+(definisce cioè, come vedremo in \secref{sec:sock_domain}, la famiglia di
+protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
+come vedremo in \secref{sec:sock_type}, lo stile di comunicazione) e
 \param{protocol} il protocollo; in genere quest'ultimo è indicato
-implicitamente dal tipo di socket, per cui viene messo a zero (con l'eccezione
-dei \textit{raw socket}).
+implicitamente dal tipo di socket, per cui di norma questo valore viene messo
+a zero (con l'eccezione dei \textit{raw socket}).
 
 Si noti che la creazione del socket si limita ad allocare le opportune
 strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
@@ -218,7 +223,7 @@ quanto specificato anche dallo standard POSIX.1g, ma non esistono a tuttora
 famiglie di protocolli che supportino diverse strutture di indirizzi, per cui
 nella pratica questi due nomi sono equivalenti e corrispondono agli stessi
 valori numerici.\footnote{in Linux, come si può verificare andando a guardare
-  il contenuto di \file{bits/socket.h} le costanti sono esattamente le stesse
+  il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
   e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
   lo stesso nome.}
 
@@ -229,7 +234,7 @@ famiglie di protocolli disponibili in Linux 
   definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
   compilato il supporto nel kernel (o si sono caricati gli opportuni moduli),
   viene definita anche una costante \const{PF\_MAX} che indica il valore
-  massimo associabile ad un dominio (nel caso 32).}
+  massimo associabile ad un dominio (nel caso il suo valore 32).}
 
 Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
 dall'utente generico, ad esempio in generale tutti i socket di tipo
@@ -255,18 +260,20 @@ seguenti costanti:
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
   altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
   byte (da cui il nome \textit{stream}).
-\item[\const{SOCK\_DGRAM}] Viene usato per mandare pacchetti di lunghezza
-  massima fissata (\textit{datagram}) indirizzati singolarmente, senza
-  connessione e in maniera non affidabile. È l'opposto del precedente. 
+\item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
+  (\textit{datagram}) di lunghezza massima fissata indirizzati singolarmente,
+  Non esiste una connessione e la trasmissione è effettuata in maniera non
+  affidabile.
 \item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
   bidirezionale, sequenziale e affidabile. Opera su una connessione con un
-  altro socket. I dati possono solo essere trasmessi e letti per pacchetti (di
-  dimensione massima fissata).
+  altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
+  massima fissata, ed devono essere letti integralmente da ciascuna
+  chiamata a \func{read}.
 \item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
   rete e alle varie interfacce. I normali programmi di comunicazione non
-  devono usarlo.
-\item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di pacchetti
-  affidabile ma in cui non è garantito l'ordine di arrivo dei pacchetti.
+  devono usarlo, è riservato all'uso di sistema.
+\item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
+  affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
 \item[\const{SOCK\_PACKET}] Obsoleto, non deve essere usato.
 \end{basedescript}
 
@@ -333,8 +340,8 @@ Gli indirizzi infatti vengono specificati attraverso apposite strutture che
 vengono utilizzate dalle altre funzioni della interfaccia dei socket, quando
 la comunicazione viene effettivamente realizzata.  Ogni famiglia di protocolli
 ha ovviamente una sua forma di indirizzamento e in corrispondenza a questa una
-sua peculiare struttura degli indirizzi; i nomi di tutte queste strutture
-iniziano per \var{sockaddr\_}, quelli propri di ciascuna famiglia vengono
+sua peculiare struttura degli indirizzi. I nomi di tutte queste strutture
+iniziano per \var{sockaddr\_}; quelli propri di ciascuna famiglia vengono
 identificati dal suffisso finale, aggiunto al nome precedente.
 
 
@@ -369,8 +376,7 @@ struct sockaddr {
 Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
 prototipo un puntatore a questa struttura; per questo motivo quando si
 invocano dette funzioni passando l'indirizzo di un protocollo specifico
-occorrerà eseguire una coversione (il \textit{casting}) del relativo
-puntatore.
+occorrerà eseguire una conversione del relativo puntatore.
 
 I tipi di dati che compongono la struttura sono stabiliti dallo standard
 POSIX.1g e li abbiamo riassunti in \tabref{tab:sock_data_types} con i
@@ -418,10 +424,10 @@ campo \type{sa\_family\_t} era storicamente un \ctyp{unsigned short}.
 Dal punto di vista del programmatore l'unico uso di questa struttura è quello
 di fare da riferimento per il casting, per il kernel le cose sono un po'
 diverse, in quanto esso usa il puntatore per recuperare il campo
-\var{sa\_family} con cui determinare il tipo di indirizzo; per questo
-motivo, anche se l'uso di un puntatore \ctyp{void *} sarebbe più immediato
-per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto
-l'uso di questa struttura.
+\var{sa\_family}, comune a tutte le famiglie, con cui determinare il tipo di
+indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *}
+sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting),
+è stato mantenuto l'uso di questa struttura.
 
 
 \subsection{La struttura degli indirizzi IPv4}
@@ -454,18 +460,18 @@ struct in_addr {
 \end{figure}
 
 L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
-internet di un'interfaccia più un numero di porta. Il protocollo IP non
-prevede numeri di porta, che sono utilizzati solo dai protocolli di livello
-superiore come TCP e UDP. Questa struttura però viene usata anche per i socket
-RAW che accedono direttamente al livello di IP, nel qual caso il numero della
-porta viene impostato al numero di protocollo.
+internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
+dettaglio il significato di questi numeri in \secref{sec:TCPel_port_num}).  Il
+protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
+protocolli di livello superiore come TCP e UDP. Questa struttura però viene
+usata anche per i socket RAW che accedono direttamente al livello di IP, nel
+qual caso il numero della porta viene impostato al numero di protocollo.
 
 Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET},
 altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
-specifica il \textsl{numero di porta} (affronteremo in dettaglio in le
-\textsl{porte} in \secref{sec:TCPel_port_num}). I numeri di porta sotto il
-1024 sono chiamati \textsl{riservati} in quanto utilizzati da servizi standard
-e soltanto processi con i privilegi di amministratore (con user-ID effettivo
+specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
+chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
+soltanto processi con i privilegi di amministratore (con user-ID effettivo
 uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
 usare la funzione \func{bind} (che vedremo in \secref{sec:TCPel_func_bind}) su
 queste porte.
@@ -505,7 +511,6 @@ struct sockaddr_in6 {
     struct in6_addr sin6_addr;     /* IPv6 address */
     uint32_t        sin6_scope_id; /* Scope id (new in 2.4) */
 };
-
 struct in6_addr {
     uint8_t       s6_addr[16];   /* IPv6 address */
 };
@@ -528,23 +533,24 @@ Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6, infine
 il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il kernel
 2.4, per gestire alcune operazioni riguardanti il multicasting.
  
-Si noti che questa struttura è più grande della \struct{sockaddr} generica
-vista in \figref{fig:sock_sa_gen_struct}, quindi occorre stare attenti a non
-avere fatto assunzioni riguardo alla possibilità di contenere i dati nelle
-dimensioni di quest'ultima.
+Si noti che questa struttura ha una dimensione maggiore della struttura
+\struct{sockaddr} generica vista in \figref{fig:sock_sa_gen_struct}, quindi
+occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
+di contenere i dati nelle dimensioni di quest'ultima.
 
 
 \subsection{La struttura degli indirizzi locali}
 \label{sec:sock_sa_local}
 
 I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
-comunicazione fra processi che stanno sulla stessa macchina (per vengono
-chiamati \textit{local domain} o anche \textit{Unix domain}); essi rispetto ai
-precedenti possono essere anche creati in maniera anonima attraverso la
-funzione \func{socketpair} (vedi \secref{sec:ipc_socketpair}). Quando però si
-vuole fare riferimento esplicito ad uno di questi socket si deve usare una
-struttura degli indirizzi di tipo \struct{sockaddr\_un}, la cui definizione si
-è riportata in \secref{fig:sock_sa_local_struct}.
+comunicazione fra processi che stanno sulla stessa macchina (per questo
+vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
+hanno la caratteristica ulteriore di poter essere creati anche in maniera
+anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
+\secref{sec:ipc_socketpair}).  Quando però si vuole fare riferimento esplicito
+ad uno di questi socket si deve usare una struttura degli indirizzi di tipo
+\struct{sockaddr\_un}, la cui definizione si è riportata in
+\secref{fig:sock_sa_local_struct}.
 
 \begin{figure}[!htb]
   \footnotesize \centering
@@ -563,12 +569,12 @@ struct sockaddr_un {
 \end{figure}
 
 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
-il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme:
-un file (di tipo socket) nel filesystem o una stringa univoca (mantenuta in
-uno spazio di nomi astratto). Nel primo caso l'indirizzo viene specificato
-come una stringa (terminata da uno zero) corrispondente al pathname del file;
-nel secondo invece \var{sun\_path} inizia con uno zero e vengono usati i
-restanti byte come stringa, senza terminazione.
+il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
+può essere un file (di tipo socket) nel filesystem o una stringa univoca
+(mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
+specificato come una stringa (terminata da uno zero) corrispondente al
+pathname del file; nel secondo invece \var{sun\_path} inizia con uno zero e
+vengono usati come nome i restanti byte come stringa, senza terminazione.
 
 
 \subsection{La struttura degli indirizzi AppleTalk}
@@ -603,7 +609,6 @@ struct sockaddr_atalk {
     uint8_t         sat_port;   /* port */
     struct at_addr  sat_addr;   /* net/node */
 };
-
 struct at_addr {
     uint16_t        s_net;
     uint8_t         s_node;
@@ -620,13 +625,130 @@ campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori
 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
 usati solo da processi con i privilegi di amministratore o con la capability
 \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella
-struttura \var{sat\_addr}, e deve essere in \textit{network order}; esso è
-composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
-valore \const{AT\_ANYNET}, che indica una rete genrica e vale anche per
-indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
-può prendere il valore generico \const{AT\_ANYNODE} che indica anche il nodo
-corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
-rete.
+struttura \var{sat\_addr}, e deve essere in \textit{network order} (vedi
+\secref{sec:sock_endianess}); esso è composto da un parte di rete data dal
+campo \var{s\_net}, che può assumere il valore \const{AT\_ANYNET}, che indica
+una rete generica e vale anche per indicare la rete su cui si è, il singolo
+nodo è indicato da \var{s\_node}, e può prendere il valore generico
+\const{AT\_ANYNODE} che indica anche il nodo corrente, ed il valore
+\const{ATADDR\_BCAST} che indica tutti i nodi della rete.
+
+
+\subsection{La struttura degli indirizzi dei \textit{packet socket}}
+\label{sec:sock_sa_packet}
+
+I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
+un'interfaccia specifica di Linux per inviare e ricevere pacchetti
+direttamente su un'interfaccia di rete, senza passare per le routine di
+gestione dei protocolli di livello superiore. In questo modo è possibile
+implementare dei protocolli in user space, agendo direttamente sul livello
+fisico. In genere comunque si preferisce usare la libreria \file{pcap}, che
+assicura la portabilità su altre piattaforme, anche se con funzionalità
+ridotte.
+
+Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
+Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
+collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
+del dispositivo e viceversa.  In questo modo, in fase di trasmissione, il
+contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
+fornito dall'utente. In fase di ricezione invece tutto il contenuto del
+pacchetto viene passato inalterato sul socket, anche se il kernel analizza
+comunque il pacchetto, riempiendo gli opportuni campi della struttura
+\struct{sockaddr\_ll} ad esso associata.
+
+Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
+livello di rete. In questo caso in fase di ricezione l'intestazione del
+protocollo di collegamento viene rimossa prima di passare il resto del
+pacchetto all'utente, mentre in fase di trasmissione viene creata una
+opportuna intestazione per il protocollo a livello di collegamento
+utilizzato, usando le informazioni necessarie che devono essere specificate
+sempre con una struttura \struct{sockaddr\_ll}.
+
+Nella creazione di un \textit{packet socket} il valore dell'argomento
+\param{protocol} di \func{socket} serve a specificare, in \textit{network
+  order}, il numero identificativo del protocollo di collegamento si vuole
+utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
+quelli disponibili in Linux sono accessibili attraverso opportune costanti
+simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
+speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
+pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
+di questi socket è una operazione privilegiata e può essere effettuati solo da
+un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
+la capability \const{CAP\_NET\_RAW}.
+
+Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
+specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
+provengono; se si vuole limitare il passaggio ad una interfaccia specifica
+occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
+
+\begin{figure}[!htb]
+  \footnotesize \centering
+  \begin{minipage}[c]{15cm}
+    \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct sockaddr_ll {
+    unsigned short  sll_family;    /* Always AF_PACKET */
+    unsigned short  sll_protocol;  /* Physical layer protocol */
+    int             sll_ifindex;   /* Interface number */
+    unsigned short  sll_hatype;    /* Header type */
+    unsigned char   sll_pkttype;   /* Packet type */
+    unsigned char   sll_halen;     /* Length of address */
+    unsigned char   sll_addr[8];   /* Physical layer address */
+};
+    \end{lstlisting}
+  \end{minipage} 
+  \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
+    \textit{packet socket}.}
+  \label{fig:sock_sa_packet_struct}
+\end{figure}
+
+Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
+\struct{sockaddr\_ll}, e la sua definizione è riportata in
+\figref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
+leggermente diverso rispetto a quanto visto finora per gli altri tipi di
+socket.  Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
+scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
+specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
+tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
+al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
+entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun
+pacchetto.
+
+Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
+\const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
+e deve essere indicato in \textit{network order}, facendo uso delle costanti
+simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
+l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
+stesso tipo (se ad esempio si hanno più schede ethernet), permette di
+selezionare quella con cui si vuole operare (un valore nullo indica qualunque
+interfaccia).  Questi sono i due soli campi che devono essere specificati
+quando si vuole selezionare una interfaccia specifica, usando questa struttura
+con la funzione \func{bind}.
+
+I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
+l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
+relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
+collegamento che si usa, ad esempio, nel caso di ethernet, questi saranno il
+MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
+ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
+pacchetti, in questo caso tutti gli altri campi devono essere nulli.
+
+Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
+\file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
+pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
+senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
+seguenti valori: \var{PACKET\_HOST} per un pacchetto indirizzato alla macchina
+ricevente, \var{PACKET\_BROADCAST} per un pacchetto di broadcast,
+\var{PACKET\_MULTICAST} per un pacchetto inviato ad un indirizzo fisico di
+multicast, \var{PACKET\_OTHERHOST} per un pacchetto inviato ad un'altra
+stazione (e ricevuto su un'interfaccia in modo promiscuo),
+\var{PACKET\_OUTGOING} per un pacchetto originato dalla propria macchina che
+torna indietro sul socket.
+
+Si tenga presente infine che in fase di ricezione, anche se si richiede il
+troncamento del pacchetto, le funzioni \func{recvmsg}, \func{recv} e
+\func{recvfrom} restituiranno comunque la lunghezza effettiva del pacchetto
+così come arrivato sulla linea.
+
 
 %% \subsection{La struttura degli indirizzi DECnet}
 %% \label{sec:sock_sa_decnet}
@@ -736,8 +858,8 @@ rispettivi prototipi sono:
   Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
   della macchina.
   
-  \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non hanno
-    errori.}
+  \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non
+    prevedono errori.}
 \end{functions}
 
 I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare
@@ -829,9 +951,9 @@ e \textit{numeric}.
 % \end{figure}
 
 Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
-indirizzo e può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La prima
-funzione è \funcd{inet\_pton}, che serve a convertire una stringa in un
-indirizzo, il suo prototipo è:
+indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
+prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
+indirizzo; il suo prototipo è:
 \begin{prototype}{sys/socket.h}
 {int inet\_pton(int af, const char *src, void *addr\_ptr)} 
 
@@ -845,13 +967,13 @@ indirizzo, il suo prototipo 
 
 La funzione converte la stringa indicata tramite \param{src} nel valore
 numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
-memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione restituisce
-un valore positivo in caso di successo, e zero se la stringa non rappresenta
-un indirizzo valido, e negativo se \param{af} specifica una famiglia di
-indirizzi non valida.
+memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione
+restituisce un valore positivo in caso di successo, nullo se la stringa non
+rappresenta un indirizzo valido, e negativo se \param{af} specifica una
+famiglia di indirizzi non valida.
 
-La seconda funzione è \funcd{inet\_ntop} che converte un indirizzo in una
-stringa; il suo prototipo è:
+La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
+indirizzo in una stringa; il suo prototipo è:
 \begin{prototype}{sys/socket.h}
   {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
   Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
@@ -893,30 +1015,32 @@ Il formato usato per gli indirizzi in formato di presentazione 
 Per evitare di rendere questa introduzione ai socket puramente teorica
 iniziamo con il mostrare un esempio di un client TCP elementare.  Prima di
 passare agli esempi del client e del server, ritorniamo con maggiori dettagli
-su una caratteristica delle funzioni di I/O che nel caso dei socket è
+su una caratteristica delle funzioni di I/O, già accennata in
+\secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
 particolarmente rilevante, e che ci tornerà utile anche in seguito.
 
 
 \subsection{Il comportamento delle funzioni di I/O}
 \label{sec:sock_io_behav}
 
-Una cosa di cui non sempre si è consapevoli quando si ha a che fare con i
-socket è che le funzioni di input/output non sempre hanno lo stesso
-comportamento che avrebbero con i normali files (in particolare questo accade
-per i socket di tipo stream). 
+Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
+le funzioni di input/output non sempre hanno lo stesso comportamento che
+avrebbero con i normali file di dati (in particolare questo accade per i
+socket di tipo stream).
 
 Infatti con i socket è comune che funzioni come \func{read} o \func{write}
 possano restituire in input o scrivere in output un numero di byte minore di
 quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
-comportamento normale per l'I/O su file; con i normali file di dati il
-problema si avverte solo quando si incontra la fine del file, ma in generale
-non è così.
+comportamento normale per l'I/O su file, ma con i normali file di dati il
+problema si avverte solo quando si incontra la fine del file, in generale non
+è così, e con i socket questo è particolarmente evidente.
 
-In questo caso tutto quello che il programma chiamante deve fare è di ripetere
-la lettura (o scrittura) per la quantità di byte rimanenti (e le funzioni si
-possono bloccare se i dati non sono disponibili): è lo stesso comportamento
-che si può avere scrivendo più di \const{PIPE\_BUF} byte in una pipe (si
-riveda quanto detto in \secref{sec:ipc_pipes}).
+Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
+fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
+byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
+sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
+\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
+\secref{sec:ipc_pipes}).
 
 \begin{figure}[htb]
   \centering
@@ -946,17 +1070,19 @@ ssize_t FullRead(int fd, void *buf, size_t count)
     return (count - nleft);
 }  
   \end{lstlisting}
-  \caption{Funzione \func{FullRead}, legge \var{count} byte da un socket }
+  \caption{Funzione \func{FullRead}, legge esattamente \var{count} byte da un
+    file descriptor, iterando opportunamente le letture.}
   \label{fig:sock_FullRead_code}
 \end{figure}
 
 Per questo motivo, seguendo l'esempio di W. R. Stevens in \cite{UNP1}, si sono
-definite due funzioni \func{FullRead} e \func{FullWrite} che eseguono la
-lettura da un socket tenendo conto di questa caratteristica, ed in grado di
+definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
+lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
 ritornare dopo avere letto o scritto esattamente il numero di byte
-specificato; il sorgente è riportato in \figref{fig:sock_FullRead_code} e
-\figref{fig:sock_FullWrite_code} ed è disponibile fra i sorgenti allegati alla
-guida nei files \file{FullRead.c} e \file{FullWrite.c}.
+specificato; il sorgente è riportato rispettivamente in
+\figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
+disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
+\file{FullWrite.c}.
 
 \begin{figure}[htb]
   \centering
-- 
2.30.2