From 276ae7fb9a1e43b6d5e5944071848094c8cc2c3b Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 1 Aug 2004 18:17:34 +0000 Subject: [PATCH] Aggiunto materiale vario sul resolver --- filedir.tex | 2 +- fileunix.tex | 10 +- img/resolver.dia | Bin 1681 -> 1653 bytes img/struct_sys.dia | Bin 2182 -> 2170 bytes listati/myhost.c | 42 ++++ process.tex | 42 ++-- sockctrl.tex | 487 +++++++++++++++++++++++++++++++++------------ system.tex | 2 +- tcpsock.tex | 52 ++--- 9 files changed, 461 insertions(+), 176 deletions(-) create mode 100644 listati/myhost.c diff --git a/filedir.tex b/filedir.tex index d72b71e..b9d4017 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1909,7 +1909,7 @@ permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e \var{st\_gid} accennati in precedenza) e l'user-ID effettivo, il group-ID effettivo e gli eventuali group-ID supplementari del processo.\footnote{in - realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli gli + realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi, eccetto il caso in cui si voglia scrivere un server NFS, ignoreremo questa diff --git a/fileunix.tex b/fileunix.tex index 950f6ff..3a0f5a5 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -296,13 +296,13 @@ usato sempre il file descriptor con il valore pi asincrona (vedi sez.~\ref{sec:file_asyncronous_io}). Quando è impostato viene generato il segnale \const{SIGIO} tutte le volte che sono disponibili dati in input sul file. \\ - \const{O\_SYNC} & apre il file per l'input/output sincrono, ogni - \func{write} bloccherà fino al completamento della scrittura di tutti dati - sul sull'hardware sottostante.\\ + \const{O\_SYNC} & apre il file per l'input/output sincrono: ogni + \func{write} bloccherà fino al completamento della scrittura di tutti i + dati sull'hardware sottostante.\\ \const{O\_FSYNC} & sinonimo di \const{O\_SYNC}. \\ \const{O\_NOATIME} & blocca l'aggiornamento dei tempi di accesso dei - file (vedi sez.~\ref{sec:file_file_times}). In Linux questa opzione non è - disponibile per il singolo file ma come opzione per il filesystem in fase + file (vedi sez.~\ref{sec:file_file_times}). Per molti filesystem questa + funzionalità non è disponibile per il singolo file ma come opzione in fase di montaggio.\\ \hline \end{tabular} diff --git a/img/resolver.dia b/img/resolver.dia index d93560911a70832471fc04cb573bd4d316bd9af8..0e596bcee6af7b58b220c58caf84dedd4701257c 100644 GIT binary patch literal 1653 zcmV-*28#I~iwFP!000001MOU0bJ{o*eb2A(kXIsX+44uzq|;7!XCFGdJJaklBd`E% zjm+3e2rv8FE7=BuKY-X4(`=MXoM6PgzS2Ec((!RVetKR;#uG_W8ne5B1X~-Aj=VRSvf({*)+uta&|3p(diAY@pl=05vy*0n-$9#E&vWmR_c*l&$tu>bX z&?ktX*O&bHBMnJ%7zCg99Pgf}E9%zxQWy+$#>Mb&xH z3-RP%GUY{h-#KO>PD10x_$`X)O5l6Hnhh%Cp`IAPV9zK?)1^I7Sr2DO`z zI+$J%I$!W++g3ZMOIlwFccL0OHRu8b&L1};~ zUsC;&0DBE`4xg zBBJ^REf?J)Bc`je@49;uuQ3{lp;bp;iY^=DB#GB$zB>E`k|xs#+#?Wb1fGk)p!0anGHg>2m~;vq^w_`k^1`QcTHFKO+caQl1Nif>IiGg>Z3x~ zO79zs3SoMVWF`Z7U(1!-V$&B+(ObB$_3i8Dzjc{VQ6>(uPL~OlqD9zUwdg2UE!y%} zh!&B0(W0YOC6`x~cr*F^7F8t;J9MiT;g;G77>cd9YfD1fMV^>}wz<31W_OQ3tO@N0`Bw|&V}?B_9^{^qXDM@*9LHI9|8b?^1Q^bR1Q^aK z0fxT)s{z-F-R-V;5+G2kM}}??NH4`R3!Vd!FJ8WhXBK8u#F28$>6B`Yw|_0NqqWGF zVt6}iwLGy_Rr~y)Cm+o%o*xY4qq*vzAM6yAW_tDWgD)Z0S&Zdp*{D*C;RAaw#t49^ z#Tf5;2CgKWo`Y5Hk6~xImfJ;}cvgjQ0m|#ct(Y54)V>~_y+f|V)HF?NNv7Tfnqcg literal 1681 zcmV;C25$KuiwFP!000001MOU0bE7sCeb298yswUo1ma_}$dMB zE*2h8;^d{jy%JzMHefplxphNkmK_uMUL@{0SNCwqhmTK-*m|UC#u9!zfWRJDluwh0 z@!9R*&+k892ZN7yS05rq-phZplq@Xy4W6k_w}ZJ5%lD(vYPACKb4Emxf|xykjE?>$ zaZE;X&}eXXWmzu`L_`pEt~^VGNZI5;P>YiVy&X)*^v5hs9(Xh;MwR2HNt~qCBZ+SZ z@9y)T!KgGd+Oc!M_L9u#B&Fm>vuRuYgkc-gOPcPRT`ZG~$syu-SsBt`M;%{`DMw{; z5TD(>`{ceWE~z}RwN-bajZVaZq%+2=e&pK3#X=wuAcWTI@Ol>$^DbiZE>iO@STbWnwP^y$5wrR+^GvwoZ3skxr>-Q)3h}Id7FBz@&=cz z^I{c}$zOCT%ISR*ghwQetZVD1IA%+U@9l0v?j=}sJNV7sU84O-NrRFBD{Hh&wt+N6 z`%|uxMw98uWZ!Zsub=Q)OxG|ALp+4)c;f)u#>4#B&LfTKVmwV!Ud{AfOei;>Q%7}D zn}nocdQRDFE}Ct_cD5%;8qxIFh1654le^)pB(a;8-!Qh87`28T1UXbJC8w6bBdU8tz z0@M-#LaoG+8hLL_(;dx)!kuw@n&LEOl#2#k@j&6;qy!~g)VWjVt$VUy@w2=t!n1*u zGk1QUi?9Ad<3}pkl)Nm2Uw;J^?A1cV)pN2NaVJDw8z;NM#R0|Iw)Gs5n9cZt*5A2p zE`=w0sg)&+as<}r2xOQeT;zo+EyBP11A%Y|jZ%g`%*9Db7Ene; zYf*BVa6YCy%CG$uGpZlZa$77TV!GV-UH7cu)dirwtk|@Z=h2v?X|igrE*(wFW6dQnOJPwYc>{{I z{cX*9Rg89{NkQ$#7i>HOV}N`wZ-2o`y2c=MFwRw~OOUR={Q9let-BVXaCKYM%TVT& zYY4kw3CHNuUC9!*?<#dNR4n1C(%259Q+x?5@%786-+P)cK@&Ss*VBZ_o<*eJwCEad zT6EO0>{)byZ@OpEz0BSZyKVXM|L*>1D57B}-A`uoBa+p!=P1qC!@f+AYaL5^RsWws z$J%4!<^nswa)aMj&wcfLw0eg1)wADq_1uJe{kE@My!FlM*GjimxL@nn*!FyhMsx=K zx-!2eYUrOJ_4;)y2;weUBpkyn5@^#R;hw2Q!a3F=;r4**0oMj_UKc$QuHhaDwCRy> z&(tH~9_x|lpV0PzYbCzwHzi3Bm<600dTt=SKo=H$!w?}~e#YJ!#d`BhFx8;w^w0LRbjPzs(iU&HTx!>uil<5-^2@*25bIJ zJgrIfZ{l6fn|M&WqbbNk#bifA0GyW{4WYaPeMiIFepFcrx;{yotYVRN-;<})9YGu*TDgzY7p@sZ%{TeWFhe))bA(@QQ6%`TR4638a$dRb^vVMqPkX|rjS z$VSoZ`t5h*ZGKCe3tL-dH(Kc=T`(~VqM{!;Heo&x2zUsghjBRF#Yn%4P`?YI-$jtz zEMt)h7NkWtqc{#Zi*iq?Sn=k5k}(Tq$UM~**xdRwNYl9H{--QVj_E*t`7wJ=&BU1q zCQm2gUW*DVcfll`-`qbnTsCMiV7dLZHv6|h5{yD#)`K8QTfg5A=GWbrKYWKWMBcu< zWklrGDj|R3amwlGkUv`m6Q0zB+J2h~OY=>$Vcn=7wmWuU@=FHgY)c7QNCcCs!5{Yi_#E~~T9fcs7@%eR z7)1oY3j)w#pNptbWqvd|v@T=^STqZH?g0b;0t1^~5`dK}+RWEDj-neLO|pAGsYm5a z@NW8_awE}dFdH5CKOs6e2(r6guQmmbHCgVWCUqO(YgVV$jf_p+UpW z(a^0#!|E5qhZpa^*6A8azmM-rfE2X_QX9|<2&hINwE^*z5BXD;l`f-* z%66dPe&aHc!wMbu38AD)d5fd8%$>S!P1zy{*Yd8o2&MxoN!JR!y}{&xl8lUZRcb^){cs|CToid8ZI}uYq^$=jWXYoN&6q38)z-R5>b%$CfaG zq&svrwW&c0%}4`CbQ}>&#;W39`dYJr%axiJS*f`>y=$H z@-^of2Iycxg7!RX)hUx_W}aD0G}NBZkc>%JYvJhGp6?MA`m%DQKD3of@8!=mlkuES zRv{Nw&l5}*CB^yW&pf>4X)tE5Vs=@GJ2Su33KX3zUD68_2oT4HPKFZ*xH!j*Gr)(H}sxUb{pz!-HB_LW!Hf0|AH-iq8WcCL*{sHH405#|9w!TiXa}H&YF* z+S!E-95u}fFg1+XBT2(0Ov`10h+yCu{ z?f{|$~B9M!bpm1^GpU-6Krlf{U*heZ!~Z`Y~^sqRG&_f|F%U(+L^Zq_1dR(@?nU9}Kgt$BbhL27@%8Av-n{r=VZBx}8qU}9}nA?jL% zXjGoYDvyGq1zH|hAIe&4L zBILF>)~}qiHFU0&xw|}&vYfq3Qku3n`+!bHC-RTFbqsuxU~%?xU1^ z>*=?Nt0Dy-6_L%Hl@algRNTZ}6&=?R^3%j$PRb{MOMYdCnLA@@1iJtr1Yj>rEzAB5 zQ>)|bdSdFA5lWf-hnbFvHgR*}5bu4O_oR zw#Hq65C*gtw#I;L*qQ*^7hAXPoMG$Nz}BRTL?OL!H3puomMJQ(CNf*pGQ~6F>Pe7{ zW5d+?nVJ}$emOi{akMh+M*A+F>aIuorv3%VwQonQs_94jZrM4*(a*@yCqK(>@kv~r z)dNm9I=jjc+Cx&hPPSWtWI{X1rtjpuN`j?`$2>_)RnUvtUWiLm7reN-!0k$DCw(dH zW~U{f z>=WZ?A0KR6b6P^aaK)UKV0QVMUB2D#@@?~}w(xmQOTeg$L#gzhBJ1TSO7g>CbfYM# w!%$)n)F7xqP#p*gVH*g=Z6P%OJ!ESxuHWRp$bU1z7T0h71C%XNwzrM|0EV+L1ONa4 literal 2182 zcmV;12zmD(iwFP!000001MOW~bDKC6e($ef+*emd7YsB_I=h{{&FpQq?Y?GYTXEQ8 z@Cb78%l`J2Fo|OjzJNsHtdeP_A@Vs$*7?3qha>sJ$NNR>+%ld;X>vY*z#TX&nWnQS znV%27e);iTF!*@!=EE$a@5R44rwd2CBFW@$=Y#7!U%nrW?(XhDyvk^vau7#1AY-F{ zX&lp$XfzsJym6eT24*y;@>+S7<~ffhH#u_>x?tyn37vkM^YkW}4c4v7cGEOYxpPb7 z^TFGz;%hJ}&5X9}?6AG0b2j0Oerq=EimxziV|vMW)$C%KW|3%;ua>nY4R++uCvD1B znP`;EFW!Df-mY({ys)vQy3s}_`GWF!l+^u*v5D6Mfk1!|dKib}T};foh|Rm;=3PYD zx%etmhrYq(s{VZhe*SH|q$Mp-n8nW_g-l6QW;AIz`xn6JJ=1tM== z-f>2(tu;daEMOkY*nD5R5r*fcM@_c^D@jPjZD&iOvQA8eF_&=Jw>eDH_6Jv`M831b5NYU8s^ zA19FuydeZ$waazTXfi*URIPJy|1_D$?7;&Gq!01)i~t{cLku7a+j(R$TU<_4p46FM zSEmXW1$@*y_5d9Opbo~bSv0@So2^4IhNPYSNy=x8@4I~$xVWADC=nxnxgGF|koT|T zcRLr^b$WNHP^tSVTMaFvO;jBaW?$HSu81?(HO>$i50TM0gCG!-KJ?BoAi`D9(pN4A zU=Mv%+BCh9g@)d0SCQM_m^Q;qY+6`kvLb0nnmJXtXH+sBfd zg+lS{(mX2K)`JhfMhR2k1M1GhQ1Bu)%EN_+voXN!Jx$Xjxn#+#xbvg>Q*YAgM#P+$ zF01}k()bvoVgbkYa%V4mgS*ZrBG>?fvBCMY_J9dQ-kAr2&=2H0?vMQwAf6k+0#3H1 zQ}&$X<31DlVAJGNn|!Z}#h)x15)+*J)g<-gW z7A`cyg*s*A=|~xgST>$ALcs4gWz@P;&z~|9QF`Jjqsf*0enlyxv5u4xHkvT<{c%{t zS%`|X5q7;I)ZhuQ^5<2SvxW1C#290)=v{~w(A z^BmC|OU|#7oYi3#bPY2x@ePNW2&%_0!(syU5N4e^Wy8#dSvAbUu3;u7zTq C3J zjE7mLPT4TCOU-(9g4>H1dytAuIqd=jhj>#-gAV9`092Yo&fRERhaRNB;_iq*;j3l2d zK=cO?oePO7vIl2(g~^hS~fX z9EvqZC>I;WdfW93mps<`q;BGZ@YG5kf!or0mQ$WzQqI%6s`<@4N1bh7#w?ld?m_ns z>>s6;KE&KIG(?Y<%?;4Tg|6X|@g_o908UmT<%hpG*8-wSHp|oExtX*1YjtZ}!)syr zS_HRWJg)Ems@#z#6eW5VW1i8)m{+2xSc>(6qP0G$n^+XJC~8quGm5%hP!vBCih4R$ ztY#lEg(Zd(p-KC|P_hp}iN#NgpB6uL<7e0fKfPzd&vEzNBXHQdy7{o(BSQ?_0zZ-T zWF9}OJyJJmy=BH?sKro=p=u1pun|Pf;-If%HEtFMAfitZ)lEoHDKEYy+KBGPln2(bep&2x+gw zk^5>6SFw1P^XipMegK#6Iq&^x?6l-sq$5z)C6K=HK!Ly|K9cjcr~vhlkL6SN_I}l@ zx|e&8Vc!b>e){ukBkS%&@57n5bGdk%`%seae)?_Ws!qWN&B%7nR789r6}NHMM92FG zc{lN^N%;tHSzmd=%=(xb>i{5B6o#8;Y9aeerj}1fdSdF%owH2+8km~s36ya!OpO2< z6XF$2jX;P!&pS1yUa&>VBWl^&JXX<1oLc-0V&y<0Ix5$?%X-c z)~|uB$2tOq^upB`1g_kDExDQi7!vQ~R@Jj8o2Hhj%`-KzJpFQbTK$w7`Fe8S^&&wt zxo+VR=%b%yclcmfZF(TklV_I^;`I=ezFfUy;S7to zB*pTbY=8L6OP2&oo=#boSyj+Ww!JnltuAi3}w9GzW^z>nzy(qFm&+jN1I z1^vnbEoFJ6r*r{crwa;MKy0?a%7Q)55Nx)h_name); + alias = data->h_aliases; + while (*alias != NULL) { + printf("Alias %s\n", *alias); + alias++; + } + if (data->h_addrtype == AF_INET) { + printf("Address are IPv4\n"); + } else if (data->h_addrtype == AF_INET6) { + printf("Address are IPv6\n"); + } else { + printf("Tipo di indirizzo non valido\n"); + exit(1); + } + alias = data->h_addr_list; + while (*alias != NULL) { + addr = inet_ntop(data->h_addrtype, *alias, buffer, sizeof(buffer)); + printf("Indirizzo %s\n", addr); + alias++; + } + exit(0); +} diff --git a/process.tex b/process.tex index 70dbce4..cbdbc1d 100644 --- a/process.tex +++ b/process.tex @@ -1066,13 +1066,13 @@ configurazione. queste variabili al programma messo in esecuzione attraverso un uso opportuno delle relative chiamate (si veda sez.~\ref{sec:proc_exec}). -La shell ad esempio ne usa molte per il suo funzionamento (come \var{PATH} per -la ricerca dei comandi, o \cmd{IFS} per la scansione degli argomenti), e -alcune di esse (come \var{HOME}, \var{USER}, etc.) sono definite al login (per -i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura +La shell ad esempio ne usa molte per il suo funzionamento (come \texttt{PATH} +per la ricerca dei comandi, o \texttt{IFS} per la scansione degli argomenti), +e alcune di esse (come \texttt{HOME}, \texttt{USER}, etc.) sono definite al +login (per i dettagli si veda sez.~\ref{sec:sess_login}). In genere è cura dell'amministratore definire le opportune variabili di ambiente in uno script di avvio. Alcune servono poi come riferimento generico per molti programmi -(come \var{EDITOR} che indica l'editor preferito da invocare in caso di +(come \texttt{EDITOR} che indica l'editor preferito da invocare in caso di necessità). Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più @@ -1089,22 +1089,22 @@ controllare \cmd{man environ}. & \textbf{Linux} & \textbf{Descrizione} \\ \hline \hline - \val{USER} & $\bullet$ & $\bullet$ & $\bullet$ & Nome utente\\ - \val{LOGNAME} & $\bullet$ & $\bullet$ & $\bullet$ & Nome di login\\ - \val{HOME} & $\bullet$ & $\bullet$ & $\bullet$ & - Directory base dell'utente\\ - \val{LANG} & $\bullet$ & $\bullet$ & $\bullet$ & Localizzazione\\ - \val{PATH} & $\bullet$ & $\bullet$ & $\bullet$ & Elenco delle directory - dei programmi\\ - \val{PWD} & $\bullet$ & $\bullet$ & $\bullet$ & Directory corrente\\ - \val{SHELL} & $\bullet$ & $\bullet$ & $\bullet$ & Shell in uso\\ - \val{TERM} & $\bullet$ & $\bullet$ & $\bullet$ & Tipo di terminale\\ - \val{PAGER} & $\bullet$ & $\bullet$ & $\bullet$ & Programma per vedere i - testi\\ - \val{EDITOR} & $\bullet$ & $\bullet$ & $\bullet$ & Editor preferito\\ - \val{BROWSER} & $\bullet$ & $\bullet$ & $\bullet$ & Browser preferito\\ - \val{TMPDIR} & $\bullet$ & $\bullet$ & $\bullet$ & Directory dei file - temporanei\\ + \texttt{USER} &$\bullet$&$\bullet$&$\bullet$& Nome utente\\ + \texttt{LOGNAME}&$\bullet$&$\bullet$&$\bullet$& Nome di login\\ + \texttt{HOME} &$\bullet$&$\bullet$&$\bullet$& Directory base + dell'utente\\ + \texttt{LANG} &$\bullet$&$\bullet$&$\bullet$& Localizzazione\\ + \texttt{PATH} &$\bullet$&$\bullet$&$\bullet$& Elenco delle directory + dei programmi\\ + \texttt{PWD} &$\bullet$&$\bullet$&$\bullet$& Directory corrente\\ + \texttt{SHELL} &$\bullet$&$\bullet$&$\bullet$& Shell in uso\\ + \texttt{TERM} &$\bullet$&$\bullet$&$\bullet$& Tipo di terminale\\ + \texttt{PAGER} &$\bullet$&$\bullet$&$\bullet$& Programma per vedere i + testi\\ + \texttt{EDITOR} &$\bullet$&$\bullet$&$\bullet$& Editor preferito\\ + \texttt{BROWSER}&$\bullet$&$\bullet$&$\bullet$& Browser preferito\\ + \texttt{TMPDIR} &$\bullet$&$\bullet$&$\bullet$& Directory dei file + temporanei\\ \hline \end{tabular} \caption{Esempi delle variabili di ambiente più comuni definite da vari diff --git a/sockctrl.tex b/sockctrl.tex index 62989d4..ea69815 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -86,12 +86,13 @@ dominio, e prevedeva solo l'utilizzo del DNS e del file statico \file{/etc/hosts}. Per questo aspetto il file di configurazione principale del sistema è -\file{/etc/resolv.conf} che contiene in sostanza l'elenco dei server DNS da -contattare; a questo si affianca il file \file{/etc/host.conf} il cui scopo -principale è indicare l'ordine in cui eseguire la risoluzione dei nomi (se -usare prima i valori di \file{/etc/hosts} o quelli del DNS). Tralasciamo i -dettagli relativi alle varie direttive che possono essere usate in questi -file, che si trovano nelle rispettive pagine di manuale. +\file{/etc/resolv.conf} che contiene in sostanza l'elenco degli indirizzi IP +dei server DNS da contattare; a questo si affianca il file +\file{/etc/host.conf} il cui scopo principale è indicare l'ordine in cui +eseguire la risoluzione dei nomi (se usare prima i valori di \file{/etc/hosts} +o quelli del DNS). Tralasciamo i dettagli relativi alle varie direttive che +possono essere usate in questi file, che si trovano nelle rispettive pagine di +manuale. Con il tempo però è divenuto possibile fornire diversi sostituti per l'utilizzo delle associazione statiche in \file{/etc/hosts}, inoltre oltre @@ -105,11 +106,11 @@ NIS,\footnote{il \textit{Network Information Service} di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei file statici \file{/etc/protocols} e \file{/etc/services}. Molte di queste -informazioni non si trovano su un DNS, e poi in un ambiente distribuito può -essere molto utile centralizzare il mentenimento di alcune di esse su -opportuni server. Inoltre l'uso di diversi supporti possibili per le stesse -informazioni (ad esempio il nome delle macchine può essere mantenuto sia -tramite \file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema +informazioni non si trovano su un DNS, ma in una rete locale può essere molto +utile centralizzare il mentenimento di alcune di esse su opportuni server. +Inoltre l'uso di diversi supporti possibili per le stesse informazioni (ad +esempio il nome delle macchine può essere mantenuto sia tramite +\file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema dell'ordine in cui questi vengono interrogati.\footnote{con le implementazioni classiche i vari supporti erano introdotti modificando direttamente le funzioni di liberia, prevedendo un ordine di interrogazione predefinito e @@ -206,38 +207,43 @@ server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni generiche di libreria usate anche dal sistema del \textit{resolver}. Il sistema del DNS è in sostanza di un database distribuito organizzato in -maniera gerarchica, la manutenzione dei dati è mantenuta in tanti server -distinti ciascuno dei quali si occupa della risoluzione del proprio -\textsl{dominio}; i nomi a dominio sono poi organizzati in una struttura ad -albero analoga a quella dell'albero dei file in un sistema unix-like, con -domini di primo livello (come i \texttt{.org}), secondo livello (come -\texttt{.truelite.it}), ecc. In questo caso le separazioni sono fra i vari -livelli sono definite dal carattere ``\texttt{.}'' ed i nomi devono essere -risolti da destra verso sinistra. Il meccanismo funziona con il criterio della -\textsl{delegazione}, un server responsabile per un dominio di primo livello -può delegare la risoluzione degli indirizzi per un suo dominio di secondo -livello ad un altro server, il quale a sua volta potrà delegare la risoluzione -di un eventuale sottodominio di terzo livello ad un altro server ancora. - -In realtà un server DNS contiene comunque una serie di altre informazioni; -ciascuna voce nel database viene chiamata \textit{resource record}, e può -contenere diverse informazioni; in genere i \textit{resource record} vengono -classificati per la \textsl{classe di indirizzi} cui i dati contenuti fanno -riferimento, e per il \textsl{tipo} di questi ultimi. Oggigiorno i dati -mantenuti nei server DNS sono sostanzialmente relativi soltanto ad indirizzi -internet, per cui in pratica c'è soltanto una classe di indirizzi utilizzata, -i dati invece possono essere di vario tipo, uno dei quali è appunto la -corrispondenza fra nome a dominio e numero IP. - -L'esistenza di vari tipi di informazioni ottenibili da un server DNS è -un'altro dei motivi per cui il \textit{resolver} prevede un insieme di -funzioni dedicato rispetto a quelle della semplice risoluzione dei nomi; la -prima di queste è \funcd{res\_init}, il cui prototipo è: +maniera gerarchica, i dati vengono mantenuti in tanti server distinti ciascuno +dei quali si occupa della risoluzione del proprio \textsl{dominio}; i nomi a +dominio sono organizzati in una struttura ad albero analoga a quella +dell'albero dei file, con domini di primo livello (come i \texttt{.org}), +secondo livello (come \texttt{.truelite.it}), ecc. In questo caso le +separazioni sono fra i vari livelli sono definite dal carattere ``\texttt{.}'' +ed i nomi devono essere risolti da destra verso sinistra.\footnote{per chi si + stia chiedendo quale sia la radice di questo albero, cioè l'equivalente di + ``\texttt{/}'', la risposta è il dominio speciale ``\texttt{.}'', che in + genere non viene mai scritto esplicitamente, ma che, come chiunque abbia + configurato un server DNS sa bene, esiste ed è gestito dai cosiddetti + \textit{root DNS} che risolvono i domini di primo livello.} Il meccanismo +funziona con il criterio della \textsl{delegazione}, un server responsabile +per un dominio di primo livello può delegare la risoluzione degli indirizzi +per un suo dominio di secondo livello ad un altro server, il quale a sua volta +potrà delegare la risoluzione di un eventuale sottodominio di terzo livello ad +un altro server ancora. + +In realtà un server DNS è in grado di fare altro rispetto alla risoluzione di +un nome a dominio in un indirizzo IP; ciascuna voce nel database viene +chiamata \textit{resource record}, e può contenere diverse informazioni; in +genere i \textit{resource record} vengono classificati per la \textsl{classe + di indirizzi} cui i dati contenuti fanno riferimento, e per il \textsl{tipo} +di questi ultimi. Oggigiorno i dati mantenuti nei server DNS sono +sostanzialmente relativi soltanto ad indirizzi internet, per cui in pratica +c'è soltanto una classe di indirizzi utilizzata, i dati invece possono essere +di vario tipo, uno dei quali è appunto la corrispondenza fra nome a dominio e +numero IP. + +L'esistenza di vari tipi di informazioni è un'altro dei motivi per cui il +\textit{resolver} prevede, rispetto a quelle relative alla semplice +risoluzione dei nomi, un insieme di funzioni specifiche dedicate +all'interrogazione di un server DNS; la prima di queste funzioni è +\funcd{res\_init}, il cui prototipo è: \begin{functions} -\headdecl{netinet/in.h} -\headdecl{arpa/nameser.h} -\headdecl{resolv.h} -\funcdecl{int res\_init(void)} + \headdecl{netinet/in.h} \headdecl{arpa/nameser.h} \headdecl{resolv.h} + \funcdecl{int res\_init(void)} Inizializza il sistema del \textit{resolver}. @@ -245,29 +251,28 @@ Inizializza il sistema del \textit{resolver}. errore.} \end{functions} -La funzione legge il contenuto dei file di configurazione per impostare il -dominio di default, gli indirizzi dei server DNS da contattare e l'ordine -delle ricerche; se non sono specificati server verrà utilizzato l'indirizzo -locale, e se non è definito un dominio di default sarà usato quello associato -con l'indirizzo locale. In genere si deve eseguire questa funzione prima di -chiamare tutte le altre. +La funzione legge il contenuto dei file di configurazione (i già citati +\file{resolv.conf} e \file{host.conf}) per impostare il dominio di default, +gli indirizzi dei server DNS da contattare e l'ordine delle ricerche; se non +sono specificati server verrà utilizzato l'indirizzo locale, e se non è +definito un dominio di default sarà usato quello associato con l'indirizzo +locale (ma questo può essere sovrascritto con l'uso della variabile di +ambiente \texttt{LOCALDOMAIN}). In genere è necessario eseguire questa +funzione direttamente in quanto viene automaticamente chiamata la prima che si +esegue una delle altre. Le impostazioni del resolver e lo stato del sistema vengono mantenute in una -serie di variabili globali contenuti in una apposita struttura interna, -definita in \file{resolv.h}, che può essere acceduta una volta che la si -dichiara con: -\includecodesnip{listati/resolv_option.c} - -Tutti i campi della struttura sono ad uso interno, l'unico che può essere -utile modificare è il campo \var{\_res.options}, che è una maschera binaria -che permette di controllare il comportamento del resolver, modificandone -alcune impostazioni direttamente da programma prima di invocare -\func{res\_init}. Le costanti che definiscono i vari bit di questo campo, con -il relativo significato sono illustrate in tab.~\ref{tab:resolver_option}, un -valore deve essere espresso con un opportuno OR aritmetico di dette costanti; -ad esempio il valore di default dato dalla costante \const{RES\_DEFAULT} è -definito come: -\includecodesnip{listati/resolv_option_def.c} +serie di variabili contenute in una apposita struttura interna che viene +definita in \file{resolv.h} ed è utilizzata come variabile globale, così che +anche un programma vi può accedure una volta che essa sia stata opportunamente +dichiarata come: \includecodesnip{listati/resolv_option.c} + +Tutti i campi della struttura sono ad uso interno, e vengono usualmente +inizializzati da \func{res\_init} in base al contenuto dei file di +configurazione e ad una serie di valori di default. L'unico campo che può +essere utile modificare è \var{\_res.options}, una maschera binaria che +contiene una serie di bit di opzione che permettono di controllare il +comportamento del resolver. \begin{table}[htb] \centering @@ -318,10 +323,37 @@ definito come: \label{tab:resolver_option} \end{table} -La funzione di richiesta principale è \funcd{res\_query}, che serve ad -eseguire una richiesta ad un server DNS per un nome a dominio completamente -specificato (quello che si chiama FQDN, \textit{Fully Qualified Domain Name}); -il suo prototipo è: +Per utilizzare questa funzionalità per modificare le impostazioni direttamente +da programma occorrerà impostare un opportuno valore per questo campo ed +invocare esplicitamente \func{res\_init}, dopo di che le altre funzioni +prenderanno le nuove impostazioni. Le costanti che definiscono i vari bit di +questo campo, ed il relativo significato sono illustrate in +tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore +deve essere espresso con un opportuno OR aritmetico di dette costanti; ad +esempio il valore di default delle opzioni, epsresso dalla costante +\const{RES\_DEFAULT}, è definito come: +\includecodesnip{listati/resolv_option_def.c} + +Non tratteremo il significato degli altri campi non essendovi necessità di +modificarli direttamente; gran parte di essi sono infatti impostati dal +contenuto dei file di configurazione, mentre le funzionalità controllate da +alcuni di esse possono essere modificate con l'uso delle opportune variabili +di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con +\texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che +controlla quante volte viene ripetuto il tentativo di connettersi ad un server +DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo +significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si +soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore + della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il +valore preso come base (in numero di secondi) per definire la scadenza di una +richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppianto +il tempo di scadenza per il numero massimo di volte stabilito da +\texttt{RES\_RETRY}. + +La funzione di interrogazione principale è \funcd{res\_query}, che serve ad +eseguire una richiesta ad un server DNS per un nome a dominio +\textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully + Qualified Domain Name}); il suo prototipo è: \begin{functions} \headdecl{netinet/in.h} @@ -332,53 +364,250 @@ il suo prototipo Esegue una interrogazione al DNS. -\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di - errore.} +\bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei + dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di + errore.} \end{functions} +La funzione esegue una interrogazione ad un server DNS relativa al nome da +risolvere passato nella stringa indirizzata da \param{dname}, inoltre deve +essere specificata la classe di indirizzi in cui eseguire la ricerca con +\param{class}, ed il tipo di \textit{resource record} che si vuole ottenere +con \param{type}. Il risultato della ricerca verrà scritto nel buffer di +lunghezza \param{anslen} puntato da \param{answer} che si sarà opportunamente +allocato in precedenza. + -Per quanto ci interessa i tipi di \textit{resource record} che vengono -utilizzati dal \textit{resolver} sono sostanzialmente i seguenti: +Una seconda funzione di ricerca, analoga a \func{res\_query}, e che prende gli +stessi argomenti, ma esegue l'interrogazione con le funzionalità addizionali +previste dalle due opzioni \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}, è +\funcd{res\_search}, il cui prototipo è: +\begin{functions} +\headdecl{netinet/in.h} +\headdecl{arpa/nameser.h} +\headdecl{resolv.h} +\funcdecl{int res\_search(const char *dname, int class, int type, + unsigned char *answer, int anslen)} + + Esegue una interrogazione al DNS. + + \bodydesc{La funzione restituisce un valore positivo pari alla lunghezza dei + dati scritti nel buffer \param{answer} in caso di successo e -1 in caso di + errore.} +\end{functions} + +In sostanza la funzione ripete una serie di chiamate a \func{res\_query} +aggiungendo opportunamente il dominio di default da cercare nella stinga +\param{dname}, fermandosi non appena trova un risultato. Il risultato di +entrambe le funzioni viene scritto nel formato opportuno (che sarà diverso a +seconda del tipo di record richiesto) nel buffer di ritorno; sarà compito del +programma (o di altre funzioni) estrarre i relativi dati, esistono una serie +di funzioni interne usate per la scansione di questi dati, per chi fosse +interessato una trattazione dettagliata è riportata nel capitolo 14 di +\cite{DNSbind}. + +Le classi di indirizzi supportate da un server DNS sono tre, ma di queste in +pratica oggi viene utilizzata solo quella degli indirizzi internet; le +costanti che identificano dette classi come valore per l'argomento +\param{class} sono riportate in +tab.~\ref{tab:DNS_address_class}.\footnote{esisteva in realtà anche una classe + \const{C\_CSNET} per la omonima rete, ma è stata dichiarata obsoleta.} + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{8cm}|} + \hline + \textbf{Costante} & \textbf{Significato} \\ + \hline + \hline + \const{C\_IN} & indirizzi internet, in pratica i soli utilizzati oggi.\\ + \const{C\_HS} & indirizzi \textit{Hesiod}, utilizzati solo al MIT, oggi + completamente estinti. \\ + \const{C\_CHAOS}& indizzi per la rete \textit{Chaosnet}, un'altra rete + sperimentale nata al MIT. \\ + \const{C\_ANY} & indica un indirizzo di classe qualunque.\\ + \hline + \end{tabular} + \caption{Costanti identificative delle classi di indirizzi per l'argomento + \param{class} di \func{res\_query}.} + \label{tab:DNS_address_class} +\end{table} + +Come accennato le tipologie di dati che sono mantenibili su un DNS sono +diverse, ed a ciascuna di essa corriponde ad un diverso tipo di +\textit{resource record}; l'elenco dei valori possibili\footnote{come + ottenibile dai file di dichiarazione \file{arpa/nameser.h} e + \file{arpa/nameser_compat.h}.} che si possono indicare per l'argomento +\param{type} è riportato in tab.~\ref{tab:DNS_record_type}; le costanti (tolto +il \texttt{T\_} iniziale) usano gli stessi valori usati per identificare i +record nei file di zona di BIND, e che normalmente sono anche usati come +\textsl{nomi} per indicare i record. + +\begin{table}[!htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|l|} + \hline + \textbf{Costante} & \textbf{Significato} \\ + \hline + \hline + \const{T\_A} & indirizzo di una stazione.\\ + \const{T\_NS} & server DNS autoritativo per il dominio richiesto.\\ + \const{T\_MD} & destinazione per la posta elettronica.\\ + \const{T\_MF} & redistributore per la posta elettronica.\\ + \const{T\_CNAME} & nome canonico.\\ + \const{T\_SOA} & inzio di una zona di autorità.\\ + \const{T\_MB} & nome a dominio di una casella di posta.\\ + \const{T\_MG} & nome di un membro di un gruppo di posta.\\ + \const{T\_MR} & nome di un cambiamento di nome per la posta.\\ + \const{T\_NULL} & record nullo.\\ + \const{T\_WKS} & servizio noto.\\ + \const{T\_PTR} & risoluzione inversa di un indirizzo numerico.\\ + \const{T\_HINFO} & informazione sulla stazione.\\ + \const{T\_MINFO} & informazione sulla casella di posta.\\ + \const{T\_MX} & server cui instradare la posta per il dominio.\\ + \const{T\_TXT} & stringhe di testo (libere).\\ + \const{T\_RP} & nome di un responsabile (\textit{responsible person}).\\ + \const{T\_AFSDB} & database per una cella AFS.\\ + \const{T\_X25} & indirizzo di chiamata per X.25.\\ + \const{T\_ISDN} & indirizzo di chiamata per ISDN.\\ + \const{T\_RT} & router.\\ + \const{T\_NSAP} & indirizzo NSAP.\\ + \const{T\_NSAP\_PTR}& risoluzione inversa per NSAP (deprecato).\\ + \const{T\_SIG} & firma digitale di sicurezza.\\ + \const{T\_KEY} & chiave per firma.\\ + \const{T\_PX} & corrispondenza per la posta X.400.\\ + \const{T\_GPOS} & posizione grografica.\\ + \const{T\_AAAA} & indirizzo IPv6.\\ + \const{T\_LOC} & informazione di collocazione.\\ + \const{T\_NXT} & dominio successivo.\\ + \const{T\_EID} & identificatore di punto conclusivo.\\ + \const{T\_NIMLOC}& posizionatore \textit{nimrod}.\\ + \const{T\_SRV} & servizio.\\ + \const{T\_ATMA} & indirizzo ATM.\\ + \const{T\_NAPTR} & puntatore ad una \textit{naming authority} .\\ + \const{T\_TSIG} & firma di transazione.\\ + \const{T\_IXFR} & trasferimento di zona incrementale.\\ + \const{T\_AXFR} & trasferimenzo di zona di autorità.\\ + \const{T\_MAILB} & trasferimento di record di caselle di posta.\\ + \const{T\_MAILA} & trasferimetno di record di server di posta.\\ + \const{T\_ANY} & valore generico.\\ + \hline + \end{tabular} + \caption{Costanti identificative del tipo di record per l'argomento + \param{type} di \func{res\_query}.} + \label{tab:DNS_record_type} +\end{table} + + +L'elenco di tab.~\ref{tab:DNS_record_type} è quello di \textsl{tutti} i +\textit{resource record} definiti, con una breve descrizione del relativo +significato. Di tutti questi però viene impiegato correntemente solo un +piccolo sottoinsieme, alcuni sono obsoleti ed altri fanno riferimento a dati +applicativi che non ci interessano, pertanto non entreremo nei dettagli del +significato di tutti quanti, ma solo di quelli usati dalle funzioni del +\textit{resolver}, che sono sostanzialmente i seguenti: \begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}} -\item[\texttt{A}] indica la corripondenza fra un nome a dominio ed un +\item[\texttt{A}] per indicare la corripondenza fra un nome a dominio ed un indirizzo IPv4, ad esempio la corrispondenza fra \texttt{dodds.truelite.it} e l'indirizzo IP \texttt{62.48.34.25}. -\item[\texttt{AAAA}] chiamato in questo modo dato che la dimensione è quattro - volte quella di un indirizzo IPv4, questo record contiene la corrispondenza - fra un nome a dominio ed un indirizzo IPv6. +\item[\texttt{AAAA}] per indicare la corrispondenza fra un nome a dominio ed + un indirizzo IPv6; è chiamato in questo modo dato che la dimensione di un + indirizzo IPv6 è quattro volte quella di un indirizzo IPv4. \item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed - un nome a dominio si utilizza invece questo tipo di record (il cui nome sta - per \textit{pointer}). -\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia - indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o - \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla - macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per - creare degli \textit{alias} in modo da associare un qualunque altro nome al + un nome a dominio si utilizza questo tipo di record (il cui nome sta per + \textit{pointer}). +\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo + stesso indirizzo (come ad esempio \texttt{www.truelite.it}, o + \texttt{sources.truelite.it}, che fanno sempre riferimento a + \texttt{dodds.truelite.it}) si può usare questo tipo di record per creare + degli \textit{alias} in modo da associare un qualunque altro nome al \textsl{nome canonico} della macchina (quello associato al record \texttt{A}). \end{basedescript} +Come accennato in caso di successo le due funzioni di richiesta restituiscono +il risultato della interrogazione al server, in caso di insuccesso l'errore +invece viene segnalato da un valore di ritorno pari a -1, ma in questo caso, a +differenza delle funzioni viste finora, non può essere utilizzata la variabile +\var{errno} per riportare un codice di errore, in quanto questo viene +impostato per ciascuna delle chiamate al sistema utilizzate, e può non avere +nessun significato nell'indicare quale parte del procedimento di risoluzione è +fallita. +Per questo motivo all'interno del resolver è stata definita una apposita +variabile di errore, \var{h\_errno} che viene utilizzata dalle funzioni del +resolver per indicare quale problema ha causato il fallimento della +risoluzione del nome. Ad essa si può accedere una volta che la si dichiara +con: +\includecodesnip{listati/herrno.c} +ed i valori che può assumere sono riportati in tab.~\ref{tab:h_errno_values}. + + +\begin{table}[!htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{10cm}|} + \hline + \textbf{Costante} & \textbf{Significato} \\ + \hline + \hline + \const{HOST\_NOT\_FOUND} & l'indirizzo richiesto non è valido e la + macchina indicata è sconosciuta. \\ + \const{NO\_ADDRESS} & il nome a dominio richiesto è valido, ma non ha + un indirizzo associato ad esso + (alternativamente può essere indicato come + \const{NO\_DATA}). \\ + \const{NO\_RECOVERY} & si è avuto un errore non recuperabile + nell'interrogazione di un server DNS. \\ + \const{TRY\_AGAIN} & si è avuto un errore temporaneo + nell'interrogazione di un server DNS, si può + ritentare l'interrogazione in un secondo + tempo. \\ + \hline + \end{tabular} + \caption{Valori possibili della variabile \var{h\_errno}.} + \label{tab:h_errno_values} +\end{table} +Insieme alla nuova variabile vengono definite anche due nuove funzioni per +stampare l'errore a video, analoghe a quelle di sez.~\ref{sec:sys_strerror}, +ma che usano il valore di \var{h\_errno}; la prima è \funcd{herror} ed il suo +prototipo è: +\begin{functions} +\headdecl{netdb.h} +\funcdecl{void herror(const char *string)} +Stampa un errore di risoluzione. +\end{functions} + +La funzione è l'analoga di \func{perror} e stampa sullo standard error un +messaggio di errore corrispondente al valore corrente di \var{h\_errno}, a cui +viene anteposta la stringa \param{string} passata come argomento. La seconda +funzione è \funcd{hstrerror} ed il suo prototipo è: +\begin{functions} +\headdecl{netdb.h} +\funcdecl{const char *hstrerror(int err)} + +Restituisce una stringa corripondente ad un errore di risoluzione. +\end{functions} +\noindent e come per l'analoga \func{strerror} restituise una stringa con un +messaggio di errore già formattato corrispondente al codice passato come +argomento (che si presume sia dato da \var{h\_errno}). -Per questo motivo il \textit{resolver} prevede delle funzioni che permettono -sia di eseguire direttamente delle interrogazione ad un server DNS, che di -controllare le modalità con cui queste vengono eseguite; diventa così -possibile modificare da programma buona parte dei parametri controllati da -\file{/etc/resolv.conf}. \subsection{La risoluzione dei nomi a dominio} \label{sec:sock_gethostbyname} -Dato che la principale funzionalità del \textit{resolver} resta quella di -risolvere i nomi a dominio in indirizzi IP, vedremo per prime le funzioni a -questo dedicate. La prima funzione è \funcd{gethostbyname} il cui scopo è -ottenere l'indirizzo di una stazione noto il suo nome a dominio, il suo -prototipo è: +La principale funzionalità del \textit{resolver} resta quella di risolvere i +nomi a dominio in indirizzi IP, per cui non ci dedicheremo oltre alle funzioni +di richiesta generica ed esamineremo invece le funzioni a questo dedicate. La +prima funzione è \funcd{gethostbyname} il cui scopo è ottenere l'indirizzo di +una stazione noto il suo nome a dominio, il suo prototipo è: \begin{prototype}{netdb.h} {struct hostent *gethostbyname(const char *name)} @@ -392,13 +621,7 @@ Determina l'indirizzo associato al nome a dominio \param{name}. La funzione prende come argomento una stringa \param{name} contenente il nome a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi vengono memorizzati in una opportuna struttura \struct{hostent} la cui -definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. In caso di -insuccesso l'errore viene segnalato da un valore nullo del puntatore, ma in -questo caso, a differenza delle funzioni viste finora, non viene utilizzata la -variabile \var{errno} per riportare un codice di errore, in quanto questo -dipende solo dalle sottostanti chiamate al sistema e può non avere nessun -significato nell'indicare quale parte del procedimento di risoluzione è -fallita. +definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. \begin{figure}[!htb] \footnotesize \centering @@ -409,29 +632,10 @@ fallita. \label{fig:sock_hostent_struct} \end{figure} -Per questo motivo all'interno del resolver è stata definita una apposita -variabile di errore, \var{h\_errno} che viene utilizzata dalle funzioni di -libreria per indicare quale problema ha causato il fallimento della -risoluzione del nome. Ad essa si può accedere una volta che la si dichiara -con: -\includecodesnip{listati/herrno.c} -ed i valori che può assumere sono i seguenti: -\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}} -\item[\const{HOST\_NOT\_FOUND}] l'indirizzo richiesto non è valido e la - macchina indicata è sconosciuta. -\item[\const{NO\_ADDRESS}] il nome a dominio richiesto è valido, ma non ha un - indirizzo associato ad esso (alternativamente può essere indicato come - \const{NO\_DATA}). -\item[\const{NO\_RECOVERY}] si è avuto un errore non recuperabile - nell'interrogazione di un server DNS. -\item[\const{TRY\_AGAIN}] si è avuto un errore temporaneo nell'interrogazione - di un server DNS, si può ritentare l'interrogazione in un secondo tempo. -\end{basedescript} - Quando un programma chiama \func{gethostbyname} e questa usa il DNS per -effettuare la risoluzione del nome, è con i valori di questi record che -vengono riempite le varie parti della struttura \struct{hostent}. Il primo -campo della struttura, \var{h\_name} contiene sempre il \textsl{nome +effettuare la risoluzione del nome, è con i valori contenuti nei relativi +record che vengono riempite le varie parti della struttura \struct{hostent}. +Il primo campo della struttura, \var{h\_name} contiene sempre il \textsl{nome canonico}, che nel caso del DNS è appunto il nome associato ad un record \texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun @@ -442,8 +646,7 @@ DNS vengono inseriti come record di tipo \texttt{CNAME}). Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o \const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la -lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una -struttura +lunghezza dell'indirizzo stesso in byte. Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre, @@ -460,8 +663,46 @@ corrispondente struttura \var{in\_addr} da indirizzara con \code{h\_addr\_list[0]}. +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \includecodesample{listati/myhost.c} + \end{minipage} + \normalsize + \caption{Esempio di codice per la risoluzione di un indirizzo.} + \label{fig:myhost_example} +\end{figure} + +Vediamo allora un primo esempio dell'uso di queste funzioni, in +fig.~\ref{fig:myhost_example} è riportato un estratto del codice di un +programma che esegue una semplice interrogazione al resolver usando +\func{gethostbyname} e stampa a video i risultati. Al solito il sorgente +completo, he comprende il trattamento delle opzioni ed una funzione per +stampare un messaggio di aiuto, è nel file \texttt{myhost.c} dei sorgenti +allegati alla guida. + + + +Con l'uso di \func{gethostbyname} normalmente si ottengono solo gli indirizzi +IPv4, se si vogliono ottenere degli indirizzi IPv6 occorrerà prima impostare +l'opzione \const{RES\_USE\_INET6} nel campo \texttt{\_res.options} e chiamare +\func{res\_init} (vedi sez.~\ref{sec:sock_resolver_functions}) per modificare +le opzioni del resolver; dato che questo non è molto comodo è stata definita +un'altra funzione, \funcd{gethostbyname2}, il cui prototipo è: +\begin{prototype}{netdb.h} +{struct hostent *gethostbyname2(const char *name, int af)} + +Determina l'indirizzo di tipo \param{af} associato al nome a dominio +\param{name}. + +\bodydesc{La funzione restituisce in caso di successo il puntatore ad una + struttura di tipo \struct{hostent} contente i dati associati al nome a + dominio o un puntatore nullo in caso di errore.} +\end{prototype} +In questo caso la funzione prende un secondo argomento \param{af} che indica +la famiglia di indirizzi da usare come diff --git a/system.tex b/system.tex index 3c06330..8359d3f 100644 --- a/system.tex +++ b/system.tex @@ -1207,7 +1207,7 @@ e \funcd{pututline}, i cui prototipi sono: \headdecl{utmp.h} \funcdecl{struct utmp *getutent(void)} - Legge una voce dal dalla posizione corrente nel registro. + Legge una voce dalla posizione corrente nel registro. \funcdecl{struct utmp *getutid(struct utmp *ut)} Ricerca una voce sul registro in base al contenuto di \param{ut}. diff --git a/tcpsock.tex b/tcpsock.tex index 7dcdaf1..bc65ae9 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -1302,7 +1302,7 @@ arrivati alla fine del file (per i socket questo significa in genere che l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un -valore negativo in caso di errore, \texttt{FullRead} restituisce il numero di +valore negativo in caso di errore, \func{FullRead} restituisce il numero di byte non letti in caso di end-of-file prematuro. @@ -1316,9 +1316,9 @@ nell'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}, che restituisce l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato alla porta 13. -In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale del -codice del nostro client. Il sorgente completo del programma -(\file{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una +In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale +del codice del nostro client. Il sorgente completo del programma +(\texttt{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una funzione per stampare un messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e può essere compilato su una qualunque macchina GNU/Linux. @@ -1418,7 +1418,8 @@ elementare, che sia anche in grado di rispondere al precedente client. Come primo esempio realizzeremo un server iterativo, in grado di fornire una sola risposta alla volta. Il codice del programma è nuovamente mostrato in fig.~\ref{fig:TCP_daytime_iter_server_code}, il sorgente completo -(\file{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli esempi. +(\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli +esempi. \begin{figure}[!htbp] \footnotesize \centering @@ -1515,8 +1516,8 @@ In fig.~\ref{fig:TCP_daytime_cunc_server_code} codice, in cui si sono tralasciati il trattamento delle opzioni e le parti rimaste invariate rispetto al precedente esempio (cioè tutta la parte riguardante l'apertura passiva del socket). Al solito il sorgente completo del -server, nel file \file{TCP\_cunc\_daytimed.c}, è allegato insieme ai sorgenti -degli altri esempi. +server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai +sorgenti degli altri esempi. \begin{figure}[!htb] \footnotesize \centering @@ -1652,11 +1653,11 @@ output. \label{sec:TCP_echo_client} Il codice della prima versione del client per il servizio \textit{echo}, -disponibile nel file \file{TCP\_echo\_first.c}, è riportato in +disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in fig.~\ref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente client per il servizio \textit{daytime} (vedi -sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27}) è -sostanzialmente identica, a parte l'uso di una porta diversa. +sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27}) +è sostanzialmente identica, a parte l'uso di una porta diversa. \begin{figure}[!htb] \footnotesize \centering @@ -1733,11 +1734,11 @@ illustriamo immediatamente. \subsection{Il server \textit{echo}: prima versione} \label{sec:TCPsimp_server_main} -La prima versione del server, contenuta nel file \file{TCP\_echod\_first.c}, è -riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto per -il client anche il server è stato diviso in un corpo principale, costituito -dalla funzione \code{main}, che è molto simile a quello visto nel precedente -esempio per il server del servizio \textit{daytime} di +La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c}, +è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto +per il client anche il server è stato diviso in un corpo principale, +costituito dalla funzione \code{main}, che è molto simile a quello visto nel +precedente esempio per il server del servizio \textit{daytime} di sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria \code{ServEcho} che si cura della gestione del servizio. @@ -2097,8 +2098,8 @@ riscrittura parziale del server, la nuova versione di questo, in cui si sono introdotte una serie di nuove opzioni che ci saranno utili per il debug, è mostrata in fig.~\ref{fig:TCP_echo_server_code_second}, dove si sono riportate la sezioni di codice modificate nella seconda versione del programma, il -codice completo di quest'ultimo si trova nel file \file{TCP\_echod\_second.c} -dei sorgenti allegati alla guida. +codice completo di quest'ultimo si trova nel file +\texttt{TCP\_echod\_second.c} dei sorgenti allegati alla guida. La prima modifica effettuata è stata quella di introdurre una nuova opzione a riga di comando, \texttt{-c}, che permette di richiedere il comportamento @@ -3141,11 +3142,11 @@ tutti i dati e della terminazione effettiva della connessione. \label{fig:TCP_ClientEcho} \end{figure} -Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale della -nostra funzione \func{ClientEcho}, in grado di gestire correttamente l'intero -flusso di dati fra client e server. Il codice completo del client, +Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale +della nostra funzione \func{ClientEcho}, in grado di gestire correttamente +l'intero flusso di dati fra client e server. Il codice completo del client, comprendente la gestione delle opzioni a riga di comando e le istruzioni per -la creazione della connessione, si trova nel file \file{TCP\_echo.c}, +la creazione della connessione, si trova nel file \texttt{TCP\_echo.c}, distribuito coi sorgenti allegati alla guida. La nuova versione è molto simile alla precedente di @@ -3437,10 +3438,11 @@ ma la struttura del programma resta sostanzialmente la stessa. In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova versione del server, la versione completa del codice è riportata nel file -\file{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella figura -si sono tralasciate la gestione delle opzioni, la creazione del socket in -ascolto, la cessione dei privilegi e le operazioni necessarie a far funzionare -il programma come demone, privilegiando la sezione principale del programma. +\texttt{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella +figura si sono tralasciate la gestione delle opzioni, la creazione del socket +in ascolto, la cessione dei privilegi e le operazioni necessarie a far +funzionare il programma come demone, privilegiando la sezione principale del +programma. Come per il precedente server basato su \func{select} il primo passo (\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato -- 2.30.2