2 - Amiga Magazine Online

sull'indirizzo del mittente. Trattandosi di una modifica fa-
cilmente implementabile, viene lasciata come esercizio al
lettore.
In teoria si potrebbe usare connect( ) anche in questo ca-
so. Ciò innanzitutto fa sì che lo stack associ al socket an-
che l'indirizzo e la porta di destinazione, rendendo quindi
possibile l'uso di send( ) e recv( ). Non solo: diventa suo
compito filtrare pacchetti da indirizzi e porte indesiderate.
I1 grande svantaggio, però, è legato alla natura stessa di
UDP. Inviando per esempio dati ad un indirizzo non esi-
stente o a una porta non allocata da nessuno, send( ) ri-
tornerà immediatamente lo stesso, non essendo contem-
plato da UDP alcun controllo sull'arrivo dei dati. Lo stack
ricevente, però, riconoscerà il pacchetto come avente de-
stinazione invalida e invierà un messaggio di errore ICMP
di basso livello allo stack mittente.
Quest'ultimo, grazie alla chiamata fatta a connect( ), sa
qual è il socket responsabile e notificherà l'errore alla pri-
ma chiamata di funzione relativa a quel socket successiva
all'am'vo dell'errore ICMP. Il che vuol dire che in teoria
l'errore potrebbe essere generato anche dopo due o tre
chiamate di rete. Per non complicare le cose e per evitare
di fare troppe assunzioni sugli effetti collaterali di certi
meccanismi TCPiIP, quindi, si è preferito non usare con-
nect( ).
Tra le chiamate a sendto( ) e recvfrom( ) è stato inserito
un ritardo, il cui valore può essere specificato da riga
comandi, che simula altre attività dell'applicazione (ela-
borazione dei dati, aggiornamento video, etc.). Le altre
righe di codice si occupano di stampare un messaggio
per ogni blocco di dati ricevuto e per ogni chiamata di
recvfrom( ) che non abbia restituito dati. E' possibile
provare con AmiTCP il programma usando lo script lo-
calnet descritto nel n. 80 di Amiga Magazine, senza bi-
sogno di collegarsi al proprio provider. Con Miami, in-
vece, basta caricare il programma senza andare in linea.
In due Shell distinte si lancerà il comando seguendo la
sintassi
UDPTest Host/A, Port/N, LocalPort/N, Delay/N
Per esempio:
Shell.l> UDPTest 127.0.0.1 4000 4001 20
She11.22 UDPTest 127.0.0.1 4001 4000 20
L'indirizzo 127.0.0.1, noto anche come localbost, corri-
sponde sempre al proprio Amiga. Si possono simulare
problemi di carico della rete interrompendo con Ctrl-C
una delle diie copie e rilanciandola dopo pochi secondi,
oppure specificando per le due copie ritardi diversi me-
diante il parametro Delay.
[...l
Byte letti: 200
Byte letti: 200
Non ricevo più dati ...
Byte letti: 200
Non ricevo più dati ........
Byte letti: 200
[...l
I1 programma presentato è alquanto primitivo. Per esem-
pio, non è previsto alcun meccanismo per eventuali pac-
chetti "chiave" che debbano essere recapitati a tutti i co-
sti. Un approccio primitivo potrebbe essere quello di in-
viarne più copie a intervalli ristretti di tempo per avere
più probabilità che essi arrivino a destinazione. Tecniche
più sofisticate prevedono il ricorso a timeout e ritrasmis-
sione dei pacchetti. Un buon esempio è descritto in Ua-
cobsonl o nella sezione 8.4 di [Stevensl. Tali pacchetti
chiave potrebbero essere marcati come speciali da un ap-
posito flag che, se impostato indica all'altro lato di resti-
tuire un pacchetto di conferma.
In luogo della singola chiamata di recvfrom( ), infine, per
applicazioni come il gioco descritto sopra sarebbe preferi-
bile usare un ciclo che ignori pacchetti obsoleti e recuperi
solo l'ultimo presente in coda.
Il futuro: MBone e RTP
A partire dal 1992 è stata attivata MBone, abbreviazione
di IP Multicast Backbone, una rete virtuale per applicazio-
ni realtime. Si tratta di una serie di computer e worksta-
tion visibili anche come "normali" host Internet, ma che
hanno un secondo indirizzo nell'intervallo 224.0.0.0 -
239.25 5.2 5 5.255 (la cosiddetta clsse D) e comunicano tra
loro con collegamenti che assicurano trasferimenti ad alta
velocità. Essa sfrutta il concetto di comunicazione UDP
multicast, ossia rivolta a più interlocutori: uno-a-molti, al-
cuni-a-molti, molti-a-molti. Nel 1996 è stato introdotto un
protocollo, RTP, che cerca di aumentare l'affidabilità delle
comunicazioni introducendo ritrasmissioni occasionali,
adattandosi ai ritardi e alla banda disponibile, senza però
il carico eccessivo di un responso per ogni dato inviato.
Una applicazione tipica è quella delle conferenze
videoiaudio, offerte dagli host nell'intervallo 224.2.*.*: più
o meno come in TV, una organizzazione o una società ri-
chiede l'uso per un determinato numero di minuti o ore
di un "canale" MBone, per la trasmissione di filmati, inter-
viste e manifestazioni. Tra gli eventi più gettonati, già pri-
ma della Marte-mania, le tante trasmissioni NASA con do-
cumentari, reportage e persino interviste con astronauti in
orbita(!).
Un esempio di output è il seguente: (segue a pag.50)