2 - Amiga Magazine Online

server. Risultato finale: entrambi i lati fermi in attesa dell'ar-
rivo di n. situazione nota anche come stallo.
La principale causa di perdita di pacchetti è il congestiona-
mento dei cosiddetti router o instradatori, responsabili del-
la gestione del traffico su Internet e paragonabili agli atleti
di una corsa a staffetta. Se in un determinato momento un
router riceve una quantità di dati superiore alle sue capa-
cità di smistamento, esso si limita a ignorare i pacchetti IP
in più (fenomeno noto come dropping), contando sul fatto
che i protocolli superiori provvedano a rispedirli prima o
poi.
In molti casi di stallo non resta che aspettare. Esistono am-
biti però in cui tale approccio è poco conveniente. Suppo-
nendo di lavorare inviando blocchi di dati, per esempio
una struttura, perché attendere n se l'applicazione sa che il
suo contenuto è reso obsoleto da n+l? Un caso tipico è un
gioco che informi l'altro computer dello stato del personag-
gio, inviando continuamente le sue coordinate, energia, abi-
lità, oggetti posseduti e via dicendo. Oppure, ancora, esisto-
no applicazioni come la trasmissione audio in cui il fattore
tempo è critico e in cui si fa uso di algoritmi adattivi in gra-
do di lavorare anche se viene persa una parte dei dati.
In tali situazioni è quindi utile UDP, protocollo "ombra" di
TCP, il quale è ben più famoso in virtù dei tanti protocolli
superiori che ad esso fanno ricorso (tra i tanti, HTTP, FTP,
SMTP, Telnet e NNTP).
Trasmissione fai-&-te
Se da parte sua TCP stabilisce una connessione con il com-
puter remoto, negozia alcuni parametri, scambia dati (con
tanto di bufferizzazione bidirezionale) e infine chiude il
collegamento, UDP non prevede nulla di tutto ciò. Esso in-
via direttamente i blocchi di dati, non garantendone l'arri-
vo. Ciò comporta un carico molto minore, innanzitutto per-
ché viene a mancare totalmente la fase di apertura e chiu-
sura del collegamento, ma anche perché in fase di scambio
dati non awiene gestione di buffer in uscita, verifica di av-
venuta ricezione o riordinamento dei dati. In virtù di ciò,
TCP è definito come un protocollo con connessione e afJZ-
dabile, mentre UDP è senza connessione e inaffidabile.
Per capire meglio le differenze, si possono paragonare i
protocolli a una comunicazione che avvenga rispettiva-
mente tramite telefono (TCP) o posta (UDP). Nel primo ca-
so, si invia una richiesta di connessione (si compone il nu-
mero finché l'abbonato non risponde), si negoziano alcuni
parametri (si chiede di parlare con la persona a cui si è in-
teressati), awiene lo scambio di dati (si parla con l'interlo-
cutore), si chiude infine la connessione (si riaggancia).
Nel secondo caso, invece, ci si limita a preparare i dati (si
scrive la lettera) e inoltrarli al destinatario (la si invia), nella
speranza che il protocollo (il servizio postale) li recapiti
con successo e che all'indirizzo indicato vi sia una applica-
zione in attesa di dati (qualcuno che legga la lettera). Nel
caso di invii multipli, inoltre, può capitare che due lettere
spedite in giorni diversi siano consegnate e quindi lette in
ordine inverso.
L'apparente povertà di funzionalità di UDP viene bilanciata
dalla maggiore flessibiliti. A seconda delle sue esigenze, in
caso di mancato arrivo di pacchetti, l'applicazione può ri-
spedirne alcuni ritenuti "chiave" o proseguire normalmen-
te. Tocca quindi al programmatore stabilire l'approccio più
consono, modellando opportunamente il codice.
Dalla teoria a h pratica
Un esempio, si sa, vale mille parole. Vediamo quindi un sem-
plice programma, il cui sorgente appare nel Listato 1. Esso si
limita a inviare e ricevere pacchetti a un'altra copia del pro-
gramma, in esecuzione sullo stesso computer o su una
macchina remota. Una comunicazione UDP awiene usan-
do funzioni analoghe a quelle usate per TCP e descritte nel
numero 81 di TransAction, analizzeremo quindi solo le dif-
ferenze rispetto al precedente articolo. Per maggiore como-
dità, si è fatto ricorso alle funzioni di autoinizializzazione e
di chiusura della libreria statica netlib, che aprono e chiu-
dono automaticamente SocketBase. Lo stesso socket viene
deallocato automaticamente dalla libreria bsdsocket.
Innanzitutto viene fatto uso di una ottimizzazione, duran-
te la ricerca dell'indirizzo remoto, viene provata prima la
funzione:
ULONG inet-addr(const UBYTE *);
Passando come parametro una stringa contenente un indirizzo
numerico (es. "192.168.12.45"), sarà restituito un valore
a 32 bit, mentre per un qualsiasi altro tipo di stringa (es.
"host.dominio.it") sarà restituita la costante INADDR-NO-
NE. Solo in quest'ultimo caso ricorreremo a gethostbyname(
), la quale è ben più dispendiosa, dovendo effettuare
la ricerca dell'indirizzo nei file di configurazione dello stack
o presso il nameserver.
I1 passo successivo è l'apertura del socket. Siamo interessati
a una comunicazione per pacchetti, quindi impostiamo il
parametro sockettype a SOCK-DGRAM:
sock = socket(AF-INET, SOCK-DGRAM, O);
A questo punto associamo il socket a una porta, ricorrendo a
bind( ), i cui parametri sono gli stessi di connect( ). Diversa-
mente da quest'ultima, però, la struttura sockaddrè relativa a
una porta locale. In tal modo il programma dall'altro lato sa
chi è stato a inviare i dati (per filtrare eventualmente pac-
chetti indesiderati) e a quale porta spedire le sue risposte:
struct sockaddr-in mysockaddr;