CAPITOLO 2


Introduzione

In questo secondo capitolo ci occuperemo dei requisiti di una applicazione multicast che permetta di controllare la sequenza degli interventi dei membri durante una sessione MBone, cioè una applicazione che stabilisca chi deve parlare e in quale ordine ciò debba avvenire. Prima di affrontare questo argomento è necessario analizzare brevemente il problema del multicast affidabile, perchè il controllore di conferenza MBone che abbiamo realizzato si basa su metodi e procedure tese a risolvere questo problema. Come è noto le applicazioni multicast si basano sul protocollo UDP che non ha caratteristiche di affidabilità; per supplire a questa mancanza si sono adottate diverse soluzioni, ma è difficile coniugare requisiti di affidabilità con requisiti di scalabilità ed efficienza. Basti pensare che alcune applicazioni multicast abbisognano di una consegna dei dati strettamente sequenziale menrte molte altre hanno caratteristiche di consegna molto meno stringenti. Si può anche verificare il caso che molte applicazioni posseggano dati identici mentre altre ne abiano bisogno, quindi si crea una forte asimmetria all'interno del gruppo. Tutto ciò inlfuenza ampiamente il progetto di un protocollo per il multicast affidabile. Come già detto in precedenza, benché uno possa progettare un protocollo per soddisfare le esigenze più stringenti, come ad esempio la consegna ordinata di un gran numero di dati secondo una sequenza ben precisa, un approccio di tal genere risulterebbe in un forte overhead con pesanti ripercussioni sull'efficienza e la scalabilità.

L'approccio sopra descritto è stato a lungo dibattuto ma negli ultimi dieci anni è natauna nuova “filosofia” chiamata ALF (Application Level Framing). ALF è stato successivamente elaborato con l'aggiunta di un meccanismo di rendezvous lasco basato sul meccanismo di distribuzione di IP multicast; da ciò è nato LWS (Light Weight Sessions). La linea guida di tale approccio consiste nel lasciare il più possibile esigenze di flessibilità ed efficienza allo strato applicativo. Quindi ALF garantisce un multicast affidabile minimo, in cui le funzioni di controllo e di recupero di errore sono espletate a livello applicativo. SRM è fortemente basato sul modello di recapito dei dati all'interno del gruppo in IP multicast: come detto nel capitolo 1, ogni membro invia dati ad un indirizzo di classe D; chi è interessato a ricevere i dati informa i router multicast tramite messaggi specifici di “join”. Quindi nessuna conoscenza dei membri è necessaria per ricevere i dati.

SRM allarga in qualche modo il concetto di apparteneza ad un gruppo multicast e rinforza l'individualità di ogni membro rendendolo responsabile della propria corretta ricezione dei dati.

Infine SRM cerca di seguire le linee guida che stanno alla base del protocollo TCP/IP. Per prima cosa SRM richiede solamente il modello base di consegna di IP, ovvero il servizio best-effort con la possibile duplicazione e il riordino dei pacchetti, e raggiunge l'obiettivo di affidabilità su base end-to-end. Nessun cambiamento o requisito particolare è richiesto allo strato IP. In secondo luogo SRM permette un controlo del traffico basato su meccanismi a finestra e algoritmi di back-off che gli permettono di adattarsi agevolmente a differenti topologie di gruppo e alle più svariate necessità di banda dei vari link.

Il primo tool ad essere stato progettato secondo la filosofia di SRM e Wb, da non confondere con il tool analizzato nel capitolo precedente, creato da McCanne e Jacobson della Berkeley University di San Francisco.

Vediamo ora alcuni aspetti relativi all'implementazione di quanto abbiamo fino ad ora discusso. Se una sorgente deve inviare dati ad N ricevitori aprendo contemporaneamente N connessioni TCP si verifica che N copie dello stesso pacchetto possono potenzialmente essere inviate su N links differenti causando in tal modo uno scarso utilizzo di banda. Inoltre la sorgente deve tener traccia dello stato di ciascuno degli N ricevitori. Usando il multicast si evitano sia il primo che il secondo tipo di problema, dal momento che al massimo una sola copia di un pacchetto, in assenza di perdite viene inviata su un link e non si deve tener traccia dello stato delle connesioni con i ricevitori. Quindi la distribuzione affidabile utilizzando il multicast pone delle problematiche totalmente differenti rispettola caso dell'unicast.

Per esempio in ogni protocolo affidabile ci deve essere chi si prende cura di rilevare le perdite e del recupero di errore. Poiché nelle comuincazioni unicast esiste un fato condiviso dalle due aplicazioni agli estremi della “connesione”, se una delle due estremità non riceve o trasmette correttamente ciò si ripecuote negativamente anche sull'altra. Ad esempio i TCP la sorgente ritrasmette i dati se dopo un certo tempo non riceve degli “acknowledgement” dal destinatario.

Tuttavia se si applica questo modo di procedere alle comunicazioni multicast sorgono molti problemi. Primo, dal momento che i pacchetti inviati implicano la ricezione di un “acknowledgement” si potrebbe verificare, cosa molto probabile, una implosione verso la sorgente di pacchetti di riscontro.

Secondo, dal momento che la sorgente è responsabile della consegna affidabile dei dati deve tener conto dello stato di ricezione di tutti i destinatari ed eventualmente della variazione del numero di quest'ultimi. Ora dal momento che con IP multicast si inviano dati ad un indirizzo senza conoscere chi sono i destinatari quanto appena detto sarebbe difficilmente realizzabile.

Infine gli algoritmi che tendono ad adattare il flusso dei dati alle condizioni di congestione della rete perderebbero il loro significato in ambiente multicast; ad esempio non ha senso calcolare il round trip time quando ci sono diversi ordini di magnitudine di differenza nel tempo di propagazione verso i diversi destinatari. Cosa sarebbe poi una finestra di congestione se il ritardo introdotto dai differenti link verso i destinatari cambiasse a seconda del destinatario?

Questi problemi illustrano come una comunicazione punto-punto e un sistema di controllo che si basi su di essa non sono scalabili per gruppi multicast molto grossi; dal momento che i membri di un gruppo hanno differenti vie di comunicazione e aderiscono o lasciano il gruppo dinamicamente il “fato condiviso” ovvero l'accoppiamento stretto fra sorgente e ricevitore perde il suo significato. Quindi, dalle considerazioni appena svolte si vede come l'affidabilità in ambiente multicast debba essere incentrata su chi riceve i dati piuttosto che su chi li invia.

Un'altra convenzione unicast che si adatta poco all'ambiente multicast ha a che fare con il vocabolario usato tra i ricevitori e i sorgenti per descrivere lo stato della loro comunicazione: un ricevitore può richiedere la ritrasmissione sia in unità dati (ad esempio il settore 5 del file pippo.c) o in termini di stato di comunicazione condiviso (ad esempio tra il segmento compreso tra il numero 2560 e 3200). Entrambi questi modelli hanno avuto successo per protocolli tipo TCP, ma dal momento che le trasmissioni multicast tendono ad avere uno stato di sincronizzazione molto più debole e diverso rispetto all'unicast l'utilizzo di ritrasmissioni basate sullo stato di comunicazione condivisa non funziona assolutamente. Per esempio, se un ricevitore aderisce al gruppo tardivamente e riceve i segmenti compresi tra 2560 e 3200 non ha assolutamente idea di cosa veniva prima dal momento che il numero di partenza della sorgente è arbitrario, e quindi non può fare nulla per ottenere la ritrasmissione corretta di quello che si è perso.



2.2) Requisiti per un multicast affidabile


Per la realizzazione di un protocollo per il multicast affidabile bisogna considerare il fatto che tutte le applicaizoni che partecipano alla sessione devono risolvere gli stessi problemi: scalabilità del protocollo di controllo, affidabilità. Come messo in evidenza nel paragrafo precedente passare dal caso unicast a quello multicast fa sorgere nuove e differenti istanze da risolvere che limitano le scelte possibili da fare nel progettare il protocollo. Inoltre si è visto che i protocolli di successo in Internet sono sempre in grado di adattarsi a diversi ordini di grandezza relativamente ad un cospicuo numero di parametri. Molti dei protocolli attualmente utilizzati soddisfano appieno i requisiti di cui abbiamo parlato per il caso unicast, ma sono difficilmente adattabili al caso in cui il ritardo , la banda e il numero di utenti varia di un fattore pari a 1000 o anche maggiore.

Per essere più chiari illustreremo di seguito le caratteristiche di Wb, prodotto da LBNL, che è stato costruito secondo le linee guida di SRM, anche se il nostro intento è quello di rendere più chiare l'idea generale che sta alla base del multicast affidabile.

In Wb ogni membro può creare una pagina e scriverci quello che vuole. Questo può essere combinato con i meccanismi tipici di privacy per limitare la sessione ai membri che posseggono la chiave.

Ogni membro è identificato da un identificatore unico, l'identificatore di sorgent, e ogni pagina è individuata da un identificatore di pagina che consiste dell'identificatore di sorgente del creatore della pagina e di un numero locale relativo al creatore.

Ogni membro che scrive sulla Wb produce un flusso di operazioni a cui sono associati dei numeri di sequenza e dei riferimenti temporali relativi alla sorgente. Ciascun flusso di operazioni porta con sé l'identificatore di pagina a cui si riferisce.

Non c'è bisogno che il flusso di operazioni arrivi secondo un ordine prestabilito dal momento che sono presenti sia dei timestamps che dei numeri di sequenza e quindi le operazioni intraprese sono svolte in modo corretto anche nel caso di fuori sequenza. Quindi i flussi di operazioni sono indipendenti per ogni sorgente e si riferiscono a pagine differenti all'interno della sessione.

Le seguenti assunzioni sono fatte nel caso di multicast affidabile:

1) I dati hanno un identificatore unico all'interno dela sessione.

2)L'identificatore di sorgente è unico all'interno della sessione e rimane lo stesso

anche se il membro in questione lascia la sessione. Ciò implica che quando si

aderisce una seconda volta può ottenere l'intera storia della sessione, compresi

i dati che avevamo lasciato in sospeso precedentemente.

3) Possiamo contare su una distribuzione dei pacchetti di tipo IP multicast.

4) Tutti i partecipanti aderiscono allo stesso gruppu multicast senza distinzione

fra sorgenti e ricevitori.


2.2) Spazio di lavoro SRM


Lo spazio di lavoroSRM è stato inteso per venire inconntro alle esigenze di Wb di cui abbiamo parlato precedentemente, fra le quali quell relativa al fatto che uno nspecifico flusso di dati ha un nome unico e persistente.

Ogni volta che un membro genera dei dati questi sono mandati in multicast all'intero gruppo e ciascun membro è responsabile di rilevare le perdite, magari esaminando i numeri di sequenza dei dati che arrivano, e di richiedere la ritrasmissione. Ora dal momento che l'ultimo oggetto della sequenza può perdersi, ciascun membro invia in multicast al gruppo periodicamente il numero più alto di sequenza ricevuto per una determinata pagina; in aggiunta, a questi messaggi che danno una idea dello stato di ricezione dei vari partecipanti alla sessione è allegato un timestamp per stimare la distanza dei vari ricevitori.

Per prevenire l'implosione di pacchetti recanti messaggi di stato relativi alla ricezione dei vari membri, si è optato per il protocollo XTP (Xpress Transport Protocol) il quale gestisce l'emissione di tali pacchetti in accordo ad un lasso di tempo casuale e impedisce l'emissione di tali pacchetti se viene rilevata dalla nostra applicazione la presenza in rete di pacchetti che trasportano la stessa informazione. In Srm il calcolo del lasso di tempo casuale che bisogna attendere prima di inviare i pacchetti è funzione della distanza in secondi dal nodo che ha richiesto la ritrasmissione.

Come per idati originali, le richieste di ritrasmissione o altri tipi di messaggio sono mandati in multicast all'intero gruppo. In questo modo una certo numero di hosts può perdere lo stesso pacchetto, ma l'host che si trova vicino la punto dove si verifica la perdita tenderà ad inviare prima una richiesta di ritrasmissione in multicast. Gli altri hosts a cui manca quel pacchetto vedendo che qualcun altro ha già chiesto la ritrasmissione non invieranno proprie richieste di ritrasmissione per quel pacchetto. La cosa interessante è che qualsiasi host abbia una copia del pacchetto in questione può mandarla in multicast e quindi aggiornare l'intero gruppo; non lo fa immediatamente, ma aspetta un cosidetto tempo di grazia, dopo il quale invia il pacchetto di cui si è chiesta la ritrasmissione. Tutti gli altri hosts che avevano quel pacchetto e che si apprestavano ad inviarlo, una volta visto che qualcun altro lo ha già inviato annullano l'emissione che avevano in programma. Qesto non richiede che tutti i membri posseggano tutti i dati della sessione, perché con il meccanismo sopra descritto per avere una consegna affidabile dei dati basta che almeno un membro possegga il dato a cui siamo interessati in quel momento. In linea teorica un pacchetto perso farebbe scattare una richiesta di ritrasmissione giusto dal membro a valle del punto dove è avvenuta la perdita e ci sarebbe una sola ritrasmissione da parte del membro che si trova immediatamente a monte, perché sarebbe il più vicino in termini di secondi a ricevere la richiesta di ritrasmisione e quindi a rispondervi. Naturalmente non è sempre così perché i ritardi introdotti dalla rete sono molto variabili e magari un membro che può risultare vicino in un determinato istante può essere difficilmente raggiungibile in un secondo momento.


2.3) Perdita e recupero dei dati


I messaggi per la gestione della sessione servono per informare le sorgenti sullo stato dei ricevitori (ad esempio quali pacchetti devono essere ritrasmessi perché alcuni non li hanno ricevuti), per determinare la perdita dei pacchetti (ad esempio attraverso il numero di sequenza), ma possono anche essere utilizzati per determinare l'identità dei partecipanti alla sessione (come abbiamo visto nel capitolo precedente ciò può essere fatto anche grazie ai pacchetti RTCP che sono limitati al 5% del traffico totale).

In una sessione molto lunga lo stato diventerebbe ingestibile se ogni membro dovesse riportare i numeri di sequenza di chiunque abbia partecipato alla conferenza fino a quel momento. Per prevenire questa inutile sovrabbondanza di informazioni lo spazio di stato viene ripartito in pagine. Un membro che volesse cercare delle pagine precedenti potrebbe inviare una richiesta per conoscere il numero di sequenza di quella pagina. Un partecipante che arrivasse tardi alla conferenza per avere una idea generale di quello che è accaduto fino a quel momento portebbe inviare una richiesta di aggiornamento.

In aggiunta al protocollo di recupero e controllo i membri utilizzano i messaggi di sessione per avere uan stima della distanza che li separa: tutti i pacchetti per quel determinato gruppo includono l'identificativo di sorgente più un timestamp che serve come già detto a misurare la distanza host to host e quindi anche il lasso di tempo da far trascorrere prima di inviare ritrasmissioni.

La richiesta di ritrasmissione differisce dai tradizionali messaggi di acknowledgement negativo (NACK) in due aspetti fondamentali: non sono indirizzati ad un host specifico, e la loro richiesta di ritrasmissione si basa sull'identificativo unico all'interno del gruppo. Quando un membro rileva una perdita programma di inviare una richiesta di ritrasmissione dopo un lasso di tempo casuale; quando tale lasso di tempo è trascorso viene inviata la richiesta e l'applicazione attende per un lasso di tempo doppio rispetto a prima, prima di chiedere ancora una ritrasmisione se non si riceve nulla. In SRM, il lasso di tempo che bisogna lasciar trascorrere prima di inviare la richiesta, è funzione della distanza stimata dalla sorgente del pacchetto. L'intervallo di tempo è scelto in una distribuzione uniforme del tipo [C1 dsa ; (C1 + C2)dsa] secondi, dove dsa è la distanza stimata dall'host A alla sorgente originaria del pacchetto che si è perso. Il numero C1 e il numero C2 sono rispettivamente due tipi di parametri che vengono impiegati nel calcolo del tempo di back-off.

Se un host A riceve il pacchetto che si era perso prima che abbia inviato la propria richiesta di ritrasmissione ovviamente annulla la richiesta che stava per fare e ricarica il timer. Ciò significa che se il timer appartiene alla distribuzione uniforme seguente:

(2^i)* [C1 dsa ; (C1 + C2)dsa], allora viene ricaricato ad un valore casuale estratto dalla distribuzione uniforme di intervallo: (2^(i + 1))* [C1 dsa ; (C1 + C2)dsa].

Quando qualche altro host, che chiameremo B, riceve dall'host A una richiesta che è in grado di esaudire, carica il proprio timer di risposta alla richiesta ad un valore appartenente alla distribuzione uniforme [D1dab , (D1 + D2) dab]. Il parametro dab è il ritardo unidirezionale stimato dall'host B ad A, e i numeri D1 e D2 sono parametri del'algoritmo di ritrasmissione che saranno discussi più avanti. Naturalmente se l'host B riceve quanto richiesto prima che il timer sia scaduto cancella completamente il timer di ritrasmissione, altrimenti allo scadere del timer l'host B invia in multicast il pacchetto che è stato richiesto. In accordo con la filosofia che spetta al ricevitore curarsi dell'integrità della ricezione, B non si preoccupa minimamente se A riceve o meno il pacchetto inviato.

Data la natura probabilistica dell'algoritmo che determina i tempi di back-off può accadere che alla perdita di un pacchetto seguano numerose richieste di ritrasmissione. Quando due o più hosts generano una richiesta per un pacchetto perso siamo in presenza di traffico ridondante che occupa banda inutilmente e sarebbe raccomandabile che la scelta di questi tempi di rientro fosse distribuita il più ampiamente possibile per evitare questo fastidioso traffico ridondante. Potrebbe verificarsi anche che un host riceva una richiesta di ritrasmissione subito dopo aver inviato proprio il pacchetto richiesto. Per evitare la ritrasmissione di duplicati si fa in modo che l'host ignori qualsiasi richiesta di ritrasmissione che gli giunga per un certo lasso di tempo dopo l'emissione del primo pacchetto. Il lasso di tempo è ancora una volta calcolato in base ai timestamps che sono inseriti nelle richieste di ritrasmissione. Nella successiva figura 1 è illustrato il concetto di recupero locale di informazione persa. A differenza di protocolli quali TCP, chi invia il pacchetto non si cura della corretta ricezione di quest'ultimo. È il ricevitore che si fa carico di notificare tramite messaggi di NACK della mancata ricezione. La ritrasmissione può essere però effettuata, come più volte ripetuto, da qualsiasi membro in possesso del pacchetto.



Figura 1: notifica, tramite messaggi di NACK, della mancata ricezione di un pacchetto. E' compito di chi riceve notificare la non corretta o mancata consegna di un pacchetto

2.3.1) Controllo di congestione


Il controllo di congestione più semplice che può essere intrapreso in un gruppo multicast è quello di assumere dei vincoli molto stretti per la banda a disposizione per la conferenza. Questo modo di procedere sarebbe indicato se i membri del gruppo utilizzano un meccanismo fuori banda per controllare la disponibilità della banda stessa. Poiché i dati all'interno della sessione hanno tutti la stessa importanza e continuano ad essere utili anche se consegnati fuori sequenza (si parla di dati idempotenti), la ritrasmissione dei dati persi e la trasmissione vera e propria di nuovi pacchetti possono avvenire in modo indipendente. Dal momento che la banda disponibile per la trasmissione è molto spesso limitata, è determinata un unica frequenza di trasmissione per controllare il throughput relativamente a tutti i possibili differenti modi di operare, mentre è l'applicazione che determina quali pacchetti inviare in accordo alla loro importanza.

Da notare infine che, come detto in precedenza, non essendoci una risposta immediata alle richieste di ritrasmissione e poiché le successive vengono ignorate dall'host che vi ha risposto per un lasso di tempo casuale, il traffico ridondante, che occuperebbe gran parte della banda a disposizione, è limitato al minimo. A ciò contribuisce anche il fatto che le richieste di ritrasmissione non viene inviata immediatamente ma si aspetta un po' per vedere se intanto qualcun altro ha già fatto la stessa richiesta. Infine i dati di cui si chiede di nuovo l'invio non sono in possesso di un unico membro, ma l'host che li possiede li ritrasmette al gruppo in accordo al già citato algoritmo di back-off.


2.3.2) Aspetti della corrente implementazione di Wb in un ottica SRM


La corrente implementazione di Wb si basa sull'assunzione tacita che ci sia una banda massima assegnata per ogni sessione. In quest'ottica ogni sessione avrebbe incorporata nell'annuncio che la rende pubblica la massima banda utilizzabile e i membri avrebbero un shaper del traffico in uscita di tipo token bucket. Attualmente questo limitatore di banda non è stato ancora implementato dal momento che i messaggi di gestione e la trasmissione vera e propria di Wb generano un traffico molto inferiore a quello per esempio generato dai tool audio e video. Tuttavia questo tipo di controllo di traffico sarebbe utile quando un membro che aderisse tardi alla sessione chiedesse la ritrasmissione di tutti i dati precedentemente inviati.

Un altro aspetto importante riguarda la priorità da dare ai dati che devono essere trasmessi; di solito si procede nel seguente modo: priorità più alta alle ritrasmissioni le relative alla pagina correntemente visualizzata, priorità media ai nuovi dati , priorità più bassa alla ritrasmissione dei dati di pagine precedenti. La memorizzazione dei dati non avviene su disco fisso: i dati delle pagine correnti sono tutti in memoria. Se i dati vengono corrotti da un bug del sistema, non essendoci alcun tipo di backup, i dati che vengono utilizzati per la ritrasmissione sono rovinati anch'essi. Ora se dati corrotti vengono immessi nel gruppo questi vi rimarranno per tutto il tempo della durata della sessione. Si può ovviare a questo tipo di inconveniente aggiungendo ad ogni pacchetto un campo per il controlo di errore a livello di applicazione. Anche in quest'ultimo caso si può notare come le funzioni di controllo e recupero di errore siano devolute al livello applicativo; in questo modo si cerca di rendere indipendente dai protocolli sottostanti l'applicazione rendendola completamente autonoma per quanto riguarda tutte quelle funzioni che di solito sono svolte dagli strati inferiori. Non a caso abbiamo parlato all'inizio del capitolo di Application Level Framing (ALF).


2.3.3) Algoritmi per il recupero dei dati

Analizziamo ora più in dettaglio gli algoritmi di recupero di errore che sono alla base della filosofia SRM e quindi del tool che lo implementata, ovvero SRM. Dal momento che hosts differenti possono rilevare la stessa perdita e quindi più hosts possono trovarsi a gestire lo stesso tipo di richiesta di ritrasmissione, l'obiettivo dell'algoritmo di richiesta e recupero di errore è quello di desincronizzare il più possibile le azioni dei vari membri per mantenere il numero di messaggi duplicati al minimo. Per rendere meno sincronizzate possibile le azioni che vengono intraprese dai vari membri ci basiamo sul ritardo che esiste fra di essi; se ci troviamo nel caso in cui ci sono più membri aventi lo stesso ritardo si cerca di rendere casuale l'invio di messaggi.

Nel seguito di questo paragrafo discuteremo più in dettaglio alcuni tipi di topologia e le loro influenze sull'algoritmo di perdita e recupero che stiamo analizzando.Analizzeremo la topologia a catena, la topologia a stella e la topologia ad albero . Per la topologia a catena il punto principale di cui tener conto è il fatto che il ritardo è funzione della distanza. Per la topologia stella bisogna invece rendere le azioni dei vari membri il più possibile casuali.

In figura 2 viene mostrata una TOPOLOGIA A CATENA in cui tutti i nodi sono membri di una sessione multicast; la topologia in esame è la più semplice che si possa esaminare dal momento che, senza ulteriori ipotesi, il ritardo dei messaggi scambiati fra i vari membri dipende esclusivamente dalla distanza fra di essi. Supponiamo che i parametri C1 (di cui abbiamo parlato nel paragrafo 2.3) e D1, parametro dell'algoritmo di recupero, siano pari a 1, mentre C2 e D2 siano invece 0. Dal momento che i timer che gestiscono le azioni si basano sul ritardo fra imembri e poiché in questo caso abbiamo stabilito un valore ben preciso sui valori dei parametri da considerare nel calcolo dell'algoritmo di trasmissione e recupero, si ha che le azioni dei vari hosts avvengono dopo un lasso di tempo deterministicamente fissato dall'algoritmo di cui sopra. Si ha quindi il timer Ds,a per la richiesta di ritrasmissione e il timer Ds,b per quello di invio di ritrasmissione. Supponiamo inoltre che sia i tempi che le distanze siano normalizzati: si ha quindi che il tempo impiegato da un pacchetto per attraversare un link è pari a 1 e che ogni link ha lughezza pari a 1.


Supponiamo che la sorgente Lj emetta un pacchetto multicast che viene poi perso nel tratto (L1,R1) e che il secondo pacchetto inviato da Lj non si perda. Chiameremo il tratto dove si è verificata la perdita, ovvero (L1,R1), link congestionato. Supponiamo inoltre che i nodi a valle del link congestionato rilevino tutti la perdita all'arrivo del secondo pacchetto. Il nodo R1 capisce che un pacchetto è stato perso al tempo t e invia una richiesta di ritrasmissione al tempo t + j; dal momento che la distanza e i ritardi sono tutti normalizzati il nodo L1 riceve tale richiesta a t + j + 1 ed invia la ritrasmissione al tempo t + j + 2. il generico nodo Rk riceverà tale pacchetto al tempo t + j + k + 2.

Bisogna notare che tutti i nodi a valle di R1 ricevono la richiesta di questo prima che il loro timer sia concluso di modo che la richiesta che avevano in programma di fare viene soppressa perchè si rendono conto che è già stata inoltrata da R1. Qyesta soppressione deterministica è facilmente realizzabile nel nostro caso di topologia a catena con ritardi fissi e normalizzati. In questo modo si può vedere come ci sia una sola richiesta, quella di R1, e una sola ritrasmissione, quella di L1. Per esempio il nodo Rk si acorge di una perdita al tempo t + k – 1, carica il proprio timer a (t + k -1) + (j + k -1) = t + 2k + j – 2, e riceve la richiesta di ritrasmissione del nodo R1 al tempo t + j + k -1, molto prima che il proprio timer sia scaduto. Se invece di utilizzare il multivast si fosse adoperata una soluzione di tipo unicast, per esempio Rk avesse mandato una richiesta di ritrasmissione a Lj in unicast, il nodo Rk non avrebbe ricevuto quanto richiesto fino al tempo t + 2j + 3k. Quindi con una topologia a catena e con un algoritmo che deterministicamente stabilisce i tempi di richiesta e ritrasmissione dei vari membri, abbiamo ottenuto che il nodo più lontano riceve il pacchetto che si era perso molto prima che se si fosse affidato ad un acomunicazione unicast con la sorgente originale del pacchetto. Questo ultimo aspetto è dovuto la fatto che sia la richiesta che la ritrasmissione vengono dai nodi immediatamente adiacenti al punto dove si è verificata la perdita.

Per quanto riguarda una TOPOLOGIA A STELLA assumiamo che tutti i link siano identici e che il centro della stella non sia un membro del gruppo multicast. Si può quindi notare in queste condizioni che, supponendo distanze e ritardi normalizzati, il tempo impiegato da un pacchetto per andare da un membro ad un altro è pari a 2 secondi se non si verificano perdite nei link.

Per una topologia a stella caricare il timer in funzione della distanza dalla sorgente non è un aspetto essenziale, dal momento che ogni membrorileva la perdita nello stesso istante. L'aspetto fondamentale è invece casualizzare le azioni quanto più possibile onde evitare una implosione di messaggi; chiameremo questo tipo di approccio “soppresione casuale”, a differenza del caso precedente in cui parlavamo di “soppressione deterministica”. Come si vedrà poi queste due procedure si fondono nel caso di topologia ad albero.




Supponiamo che il nodo N1 emetta un pacchetto che si perde sul link immediatamente adiacente, e quindi che i restanti G - 1 membri del gruppo si accorgano della perdita nelo stesso istante. Supporremo inoltre che i parametri C1 e D1 siano pari a 0; dal momento che tutti rilevano la perdita e ricevono richieste nello stesso istante non cè bisogno che i parametri C1 e D1 amplifichino le differenze fra i vari ritardi. L'unico vantaggio che si può trarre dal settare C1 ad un valore superiore di 1 è quello di evitare richieste non necessarie da pacchetti fuori sequenza e nell'assicurare un minimo ritardo quando si ricarica il timer.

Se C2 è al massimo 1 ci saranno sempre G-1 richieste, essendo G il numero dei membri. Riducendo C2 si riduce anche il numero delle richieste ma aumenta il tempo che bisogna attendere prima che una richiesta sia inviata. Se C2 > 1 il numero atteso di richieste sarà all'incirca 1 + (G – 2)/C2 e il ritardo di attesa fino all'emissione della prima richiesta sarà 2*C2/G secondi. Infatti i G – 1 nodi rilevano la perdita nello stesso istante e tutti quanti caricano il timer ad un valore un compreso nell'intervallo di ampiezza 2*C2; se il primo timer scade al tempo t tutti gli altri G – 2 membri ricevono la richiesta di ritrasmissione al tempo t + 2, quindi il numero atteso di richieste duplicate è pari al numero atteso di timer che scadono nel'intervallo [t , t + 2].

Se C2 e pari a G il numero atteso di richieste sarà G e il tempo atteso fino alla prima richiesta sarà 2/G secondi.

Da notare come se N2 fosse stata la sorgente del pacchetto perso, l'unico nodo che avrebbe inviato la richiesta di ritrasmissione sarebbe stato N1 e tutti gli altri membri avrebbero ricevuto tale richiesta nello stesso momento. Le stesse considerazioni svolte sopra si applicano la parametro D2 per quanto riguarda la ritrasmissione .


L'ultimo tipo di topologia che analizzeremo è quella ad ALBERO. L'algoritmo per il recupero dei dati persi in una topologia ad albero, impiega sia la soppresione deterministica, utilizzata nelle topologie a catena, che quella casuale, d'impiego nelle toplogie a stella. Consideriamo una topologia ad albero con N nodi, dove i nodi interni hanno grado pari a P. Una topologia ad albero combina sia aspetti tipici delle topologie a catena che di quelle a stella. Il valore del timer dovrebbe essere funzione della distanza per permettere di sopprimere i timer di richiesta e ritrasmissione dei nodi che si trovano verso i rami più lontani. Inoltre bisogna rendere casualli le azioni intraprese per evitare il ben noto fenomeno d'implosione di cui abbiamo parlato prima, per i nodi che si trovano allla stessa distanza dalla sorgente e che quindi emetterebbero, se in presenza di un algoritmo deterministico, tutti nello stesso istante. Si vedrà nel seguito di questo paragrafo come il comportamento dell'algoritmo di recupero dipenda dalla distanza della sorgente dal punto in cui si verifica la perdita e dal rapporto fra i due parametri C2 e C1.

Assumiamo che il nodo S sia la sorgente e che nel link (B,A) si abbia una perdita. Chiameremo i nodi dalla parte della sorgente di tale link ( compreso B) nodi “buoni”, perchè ricevono senza problemi, mentre i nodi a valle (compreso A)saranno chiamati nodi “cattivi”. Il nodo A si accorge di una perdita quando riceve, al tempo t, il pacchetto successivo emesso da S. Chiameremo il nodo A nodo di livello 0, mentre tutti gli altri nodi che si trovano a valle saranno nodi di livello i, a seconda della disatnza, calcolata in numero di link da attraversare, che li separa dal nodo A.

Assumiamo che la sorgente del pacchetto perso sia ad una distanza j da A. Quindi il timer di richiesta di ritrasmissione di A sarà esaurito a t + (C1)*j + U1*[C2] *j dove U1*[C2] denota una variabile uniformemente distribuita fra 0 e C2. Assumendo che la richiesta del nodo A non venga soppressa, un nodo di livello i riceverà tale richiesta ad un tempo t + i + (C1)*j + U1*[C2] *j.

Il nodo B riceverà la richiesta di A nell'istante t + 1 + (C1)*j + U2*[C2] *j.

Un nodo “cattivo” si renderà conto della perdità nell'istante :

t + i + (C1)*(i + j) + U1*[C2] *(i + j).

Da notare che indipendentemente dai valori che assumono la funzione U1*[C2] e la funzione U2*[C2] un nodo di livello i riceve la richiesta di A nell'istante t + i + C1 *j + (C2)*j e che il timer di tale generico nodo non si esaurisce prima di t + i + (C1)*(i + j) , come facilmente dimostrabile.

Se t + i + (C1)*j + (C2)*j < t + i + (C1)*(i + j) , cioè se (C2/C1)*j < i allora il nodo di livello i vedrà sempre il proprio timer soppresso dalla richiesta del nodo di livello 0. Quindi più è piccolo il rapporto C2/C1, minore sarà il numero di livelli che invieranno duplicati della richiesta eseguita dal nodo di livello 0. quesat relazione dimostra inoltre come mai il numero di richieste duplicate o ritrasmissioni duplicate sia più piccolo quando la sorgente, del pacchetto perso o della richiesta di ritrasmissione, si trovi vicino al link dove è avvenuta la perdita.

Bisogna notare che il parametro C1 svolge due diverse funzioni: un valore più piccolo per C1 fa in modo che il nodo B riceva il prima possibile la richiesta di ritrasmissione,

mentre un valore maggiore permette di sopprimere un maggior numero di richieste degli altri nodi. Per il parametro C2 avviene la stessa cosa: un valore piccolo permette al nodo B di ricevere prima una richiesta di ritrasmissione, mentre per topologie come quella a stella un grande valore di C2 permette di evitare richieste multiple da parte d i membri che si trovano alla stessa distanza dal link dove si è verificata la perdita. Considerazioni simili si applicano ai parametri D1 e D2 nella determinazione dei valori del timer di ritrasmissione.

Termina qui la lunga introduzione che mirava a dare una idea di massima su quali possono essere le problematiche e le soluzioni che un multicast affidabile può stimolare. Abbiamo visto innanzi tutto che è il ricevitore a farsi carico della notifica della mancata ricezione, e come ogni singola azione sia intrapresa solo dopo che un timer sia esaurito, a patto che quello che dovevamo fare non sia già stato fatto da qualcun altro. Quindi il ricevitore che vuole avere la ritrasmissione di un pacchetto non invia imediatamente la richiesta ma attende per vedere se qualcun altro l'ha già inoltrata e in caso affermativo ricarica il proprio timer in attesa che arrivi quanto desiderato.

Stessa cosa avviene dalla parte di chi riceve una richiesta di ritramissione; non si invia immediatamente il pacchetto ma si attende lo scadere di un timer per vedere se un altro membro a già provveduto alla ritrasmissione. Tutto ciò comporta un alleggerimento del traffico di controllo che altrimenti diventerebbe non solo voluminoso ma anche soggetto a picchi improvisi derivanti da azioni sincronizzate dei vari membri.



2.3.4) Recupero locale dei dati


Con l'algoritmo di recupero dei dati persi che abbiamo prima descritto, anche e si eprde un pacchetto su un link che porta ad un solo membro, la richiesta e la ritrasmissione del pacchetto sono mandate in multicast all'intero gruppo. Nel caso in cui la zona affetta dala perdita sia piccola, l'occupazione di banda utile per il recupero dei dati può essere ridotta se le richieste e le ritrasmisioni sono inviate in multicast ad un area ristretta.Gli scenari che potrebbero beneficiare di un algoritmo di recupero locale sono quelli in cui si verificano perdite persistenti verso un gruppo di membri vicini o quell in cui unmembro che aderisce in ritardo richieda l'aggiornamento dei dati fino a quel momento. Sembra che la perdita di pacchetti in una sessione multicast tenda ad avvenire verso la periferia piuttosto che sul “backbone” e inoltre più esteso è il gruppo , maggiori sono le possibilità che unpacchetto si perda lungo l'albero di distribuzione, anche in assenza di punti di persistente congestione.

l'implementazione di un efficiente algoritmo di recupero locale è ancora allo studio, tuttavia sono stati proposti dei meccanismi per realizzarlo. Più precisamente sono stati proposti dei meccanismi per limitare la visibilità delle richieste e delle ritrasmissioni.

Si suppone che il membro che invia la richiesta possegga una qualche conoscenza rigaurd oai membri vicini che hanno avuto perdite recenti. Chiameremo “vicinato di perdita “ un gruppo di membri che condividono le stesse perdite. I nodi terminali non devono conoscere la topoogia di rete, ma possono informarsi sul “vicinato di perdita” tramite informazioni contenute nei messaggi di sessione. Chiameremo perdita locale una perdita che interessa un ristretto numero di partecipanti rispetto al numero totale di partecipanti. Per identificarere i membri che condividono le stesse perdite possiamo ipotizzare che imessaggi di sessione includano un campo in cui è specificata la frazione dei dati per cui è stato settato un timer di ritrasmissione e un ulteriore campo in cui sia presente l'identificativo di tali dati (ad esempio il numero di sequenza e il nome della sorgente che li individuano unicamente all'interno della sessione). Un membro potrebbe inviare una richiesta con visibilità locale quando perdite recenti sono condivise ad un area limitata. Se non si riceve risposta la richiesta successiva avrà una visibilità più ampia.

2.3.4.1) Administrative scoping

Un metodo semplice per il recupero locale dei dati potrebbe essere la cosidetta “visibilità amministrativa”, o meglio administrative scoping, propria di IP multicast.

Un membro che ritenga che il vicinato di perdita e la potenziale sorgente di una ritrasmissione si trovino nella sua area di visibilità amministrativa, può inviare le richieste o le ritrasmissioni solo a quell'area, limitando quindi il traffico globale.



Figura :Scelta degli ambiti di visibilità in ip multicast



2.3.4.2) Gruppi multicast separati

Un altro meccanismo ancora allo studio potrebb essere quello di gruppi multicast separati. In questo schema colui nche inoltra la richiesta crea un gruppo multicast separato e invita i membri vicini ad unirsi a tale gruppo; naturalmente deve includere qualcuno in possesso dei dati mancanti e quindi in grado di inviare le ritrasmissioni.

Questa tecnica potrebbe risultare utile quando ci sia una perdita persistente su un link o quando un membro aderisce tardivamente alla sessione .


2.3.4.3) Visibilità limitata con TTL


Un terzo possibile meccanismo potrebbe essere basato sul Time-To-Live per limitare la visibilità dei messaggi di sessione. Nell 'implementazione corrente di Ip multicast ad ogni link (più precisamente ad ogni tunnel) è associata una soglia, che di default è pari ad 1. La soglia è il minimo valore di TTL che il pacchetto deve avere per essere inoltrato su quel link ed è quindi utilizzata per limitare la visibilità. Ogni router multicast decrementa il TTL del pacchetto inoltrato di un'unità; per limitare la visibilità dei messaggi un generico membro può settare il TTL dei propri pacchetti in modo opportuno. Se il partecipante include in un campo aggiuntivo il TTL con cui originariamente il pacchetto era stato emesso, chi lo riceve può rispondere al messaggio semplicemente settando il proprio TTL allo stesso valore.

La versione più semplice dell'algoritmo di recupero locale basato su TTL è quello ad un passo. Un pacchetto di richiesta inviato con TTL pari ad h otterrà risposta con TTL pari a h + k, dove k è il numero di “salti” fino al richiedente. In questo modo la ritrasmissione raggiungerebbe tutti i membri che hanno ricevuto la richiesta originaria.

Un algoritmo a due passi è comunque molto più efficace nel limitare l'occupazione di banda; alla prima ritrasmisione il TTL del pacchetto è settato al valore di quello della richiesta. La ritrasmissione include il nome del membro la cui richiesta ha fatto scattare la ritrasmissione. Successivamente il richiedente, una volta ricevuto il pacchetto desiderato, invia quest'ultimo con lo stesso TTL con il quale aveva inviato la richiesta; in questo modo siamo sicuri che tutti i membri, che avevano originariamente visto la richiesta, ricevono anche il pacchetto di riparazione.



2.4) Attuale panorama di ricerca sul Multicast affidabile


La letteratura è ricca di architetture che cercano di risolvere il problema di un multicast affidabile e li vedremo brevemente nel seguito di questo paragrafo.

Xpress Transport Protocol (XTP) è stato concepito per le comunicazioni sia unicast che per le comunicazioni punto-multipunto multicast. La comunicazione affidabile che stiamo analizzando si basa sui NACK. La sorgente può anche iniziare una procedura di handshake per controllare lo stato dei ricevitori. In questo caso ogni ricevitore aspetta un tempo casuale, all'interno dello slot temporale assegnatogli, prima di inviare i pacchetti di controllo onde evitare una implosione di messaggi verso la sorgente. In XTP sia i routers che i ricevitori possono imporre un rate massimo e un burst massimo nei confronti della sorgente.

Ci sono poi altre proposte basate sull'uso di Servers secondari che dovrebbero gestire le ritrasmissioni all'interno di un subgruppo multicast. Un protocollo di questo tipo, chiamato Log Based Receiver-reliable Multicast (LBRM), opera nel seguente modo: l'affidabilità in ricezione si basa su dei servers, primari e secondari, su cui il ricevente si registra. Il membro interessato a ricevere una ritrasmissione invia la richiesta al server secondario il quale si occupa di contattare il server primario per la ritrasmissione. Sia il ricevitore che il server secondario usano sia richieste deterministiche (cioè caricano il timer di richiesta ad un valore ben preciso) sai richieste casuali per scegliere che tipo di ritrasmissione desiderano, ovvero se in multicast oppure unicast.

LBRM adopera un sistema di “heartbeats” che invia messaggi di sessione con più frequenza subito dopo l'emissione dei dati. In un ambiente in cui il rate di trasmisione è molto basso gli heartbeat permettono ai ricevitori di accorgersi prima delle perdite.

Mentre un sistema con heartbeat non sarebbe appropriato per applicazioni come Wb, dove la congestione potrebbe essere causata da multiple sorgenti che mandano dati contemporaneamente, potrebbe risultare utile per una applicazione in cui il numero masssimo di sorgenti che inviano dati nello stesso istante è limitato. Come SRM e LBRM, il Reliable Multicast Transport Protocol (RMTP) include fra i suoi obiettivi la scalabilità e l'affidabilità di ricezione devoluta al ricevitore stesso. RMTP raggiunge questi obiettivi adoperando i Designated Routers in ogni regione del gruppo multicast, dove questi si occupano delle ritrasmissioni. Esite tuttavia il problema della designazione dei router per un gruppo multicast.

Local Group Concept è proposto in dove il gruppo multicast è suddiviso in sotto gruppi, ciascuno rappresentato da un Controllore di gruppo che si occupa delle ritrasmissioni per quell'insieme di membri. Il controllore non è un router o un server separato, ma un membro del gruppo stesso. Hofmann ha proposto delle tecniche per definire i controllore del sottogruppo in modo dinamico, ma non scende in dettaglio nella definizione di gruppo locale che dovrebbe essere sottoposto a tale controllo.



2.5)Il controllore di conferenza MBone: una possibile implementazione


Abbiamo fin qui visto quale sia la filosofia che sta alla base di un multicast affidabile, ovvero SRM, che tende a tenere ad un livello molto basso il livello del traffico dei messaggi di controllo che i vari membri si scambiano. Abbiamo poi analizzato una implementazione di tale protocollo in Wb, della LBNL, che fa vedere come, attraverso la casualizzazione delle azioni intraprese dai vari membri, sia possibile realizzare un tool di videoconferenza robusto e affidabile che richiede un traffico di controllo minimo. Ora nel panorama dei tools per videoconferenza su MBone ci siamo imbattuti in diverse applicazioni che gestiscono differenti aspetti e risolvono alcune problematiche, ma non esiste un controllore vero e proprio di conferenza che permetta in modo univoco di stabilire un ordine ben preciso per gli interventi che ogni membro desidera compiere. Succede infatti che sovente una sessione di videoconferenza su MBone si riduca ad un lungo monologo di qualche membro con tutti gli altri che lo ascoltano come tanti passanti radunati attorno ad una attrazione. Risulta infatti difficile gestire gli interventi perché, essendo tutti i partecipanti paritetici, chiunque può parlare quando vuole e quindi per evitare confusione i partecipanti preferiscono ascoltare chi si prende la briga di parlare. Ci possono essere diverse forme di controllo all'interno della conferenza: ci può essere un tipo di controllo per così dire automatico, in cui un certo tempo è assegnato ad ogni intervento dopodiche vengono ignorati i flussi audio e video che sono emessi da quest'ultimo; opppure si può optare per un controllo di tipo umano, ovvero si prevede l'esistenza di un moderatore che gestisca l'ordine dei vari interventi. E' singolare che trattando problemi relativi alla gestione degli interventi ci si imbatta inevitabilmente in problemi di tipo sociale: è infatti ancora aperta la polemica sul controllo di conferenza. Infatti c'è chi è favorevole ad un controllo centralizzato che indipendentemente dal volere dei partecipanti stabilisca chi deve parlare o deve tacere, c'è chi è invece favorevole ad un controllo di tipo meno imparziale ma pur sempre rigido in favore di un controllo che diversi autori definiscono sociale, dove si stabilisce insieme chi è il moderatore, se lo si deve cambiare dando la carica ad un altro, chi è ammesso a prendere queste decisioni.

La raccomandazione H.332 permette quest'ultimo tipo di controllo ma non è ben chiaro come implementi tali funzioni.

Per quanto riguarda il lavoro da me svolto mi sono posto in un ottica ben diversa. Mi sono reso conto che si parla molto del fatto che internet e soprattutto IP multicast permette una vera e propria interazione democratica fra i membri di una sessione; è anche evidente che tutte le applicazioni da me prese in esame tendono a rafforzare questa democrazia in MBone sottolineando che ogni membro si trova sullo stesso piano di tutti gli altri. Ora tutta questa voglia di rendere tutti uguali non tiene conto del fatto che spesso ci sono persone assolutamente non interessate ad una conferenza a cui tuttavia possono aderire creando confusione con i propri interventi o prevaricando altre persone che magari hanno qualcosa di più interessante da dire.

La nostra idea è abbastanza semplice: dal momento che la gestione degli interventi va in qualche modo regolata abbiamo bisogno di qualcuno che satbilisca chi deve parlare e in quale ordine. Per fare questo c'è bisogno di una persona che sappia chi vuole parlare, cosa questi vuole dire, e quando ciò sarà possibile. Come risulta chiaro da quanto appena detto la democrazia e paritecità degli interventi viene eliminata, o quanto meno sottoposta ad un controllore che modera l'azione dei vari membri. Ulteriori aspetti del problema riguardano cosa effettivamente il generico partecipante voglia dire e come notificare a tutti gli altri l'ordine degli interventi, chi li vuole fare e se eventualmente un intervento, che in precedenza era stato messo in lista di attesa, è stato cancellato. Vediamo che già sono sorti diversi problemi che richiedono una attenta analisi.

Nei paragrafi precedenti ci siamo soffermati sul multicast affidabile, in quanto le tematiche sollevate da tale ricerca forniscono una base utile di partenza per l'implementazione del controllore che ci apprestiamo a descrivere. Il problema principale è infatti quello di far condividere ad un elevato numero di utenti multicast che prendono parte alla sessione un insieme di informazioni relative allo stato delle richieste d'intervento che sono approvate da un moderatore. Ci troviamo difronte ancora una volta al problema del multicast affidabile; ci si può chiedere come mai non si sia scelta una soluzione di tipo unicast in cui magari il moderatore informa ad uno ad uno i vari partecipanti sullo stato della conferenza. La domanda ce la siamo posta ma, considerando il fatto che il moderatore avrebe dovuto tener traccia dello stato di ricezione di un elevato numero di connessioni, abbiamo optato per la realizzazione di una applicazione basata su MBone. Già nel paragrafo precedente ci siamo resi conto che è necessario limitare al minimo indispensabile l'occupazione di banda da parte di messaggi di gestione e di controllo.


2.5.1) Funzioni del controllore di conferenza

Quindi chiariamo qui di seguito, per maggior chiarezza, quanto detto in questo paragrafo; le considerazioni che verranno svolte servono a dare una idea generale di cosa facciano il nostro moderatore e i membri che partecipano ad una conferenza da questi gestita. Nel capitolo successivo illustremo la struttura del protocollo che sta alla base della nostra applicazione; vedremo quali tipi di messaggi i membri e il moderatore si scambiano e le azioni intraprese alla ricezione di tali messaggi.

Chiunque voglia creare una sua propria sessione su MBone utilizza SDR, uno dei tools che abbiamo illustrato nel paragrafo precedente; tramite SDR poi il creatore annuncia quando si terrà la conferenza, quali tools verranno impiegati, l'indirizzo multicast e le porte da utilizzare. SDR prevede anche la possibilità di annunciare diversi tipi di tools dal momento che è possibile scrivere degli script che vengono utilizzati come sorgente da SDR per l'annuncio di sessione. In questo modo abbiamo pensato che il moderatore della conferenza può essere il creatore stesso della sessione: egli crea la sessione, l'annuncia e insieme ai tools video e audio, che probabilmente verranno utilizzati, egli annuncia anche che s'impiegherà un controllore di conferenza. I vari membri che ricevono l'annuncio di sessione avviano Vic e Vat e il controllore; quest'ultimo confronta l'indirizzo IP della macchina dove viene avviato con l'indirizzo del creatore di sessione; se questo coincide con quello della macchina su cui il programma è in esecuzione quest'ultimo parte in modalità “moderatore”, altrimenti si avvia in modalità “ascoltatore”. Il controllore di conferenza svolge differenti funzioni a seconda che si avvii in modalità “moderatore” o in modalità “ascoltatore”.


Se si è moderatore l'applicazione svolge le seguenti funzioni:














figura n.6: finestra di dialogo del moderatore per dare la parola ad un partecipante





figura n.7: lista delle domande giacenti (a sinistra) e di quelle approvate (a destra)




Le azioni svolte dall'applicazione in modalità ascoltatore sono le seguenti:



figura n. 8: finestra per l'invio di una domanda al moderatore







figura n. 10: lista dell'ascoltatore delle domande inviate da questo (a sinistra) e di quelle approvate dal moderatore



figura n. 11: finestra di dialogo dell'acoltatore per cancellare una richiesta d'intervento








Abbiamo quindi esaminato le azioni intraprese dal moderatore e dall'ascoltatore, ma non sappiamo in quale ordine avvenga tutto ciò e quale sequenza di operazioni venga intrapresa alla ricezione dei vari tipi di messaggi.

Nel capitolo successivo spiegheremo in modo dettagliato come le funzioni appena viste siano implementate; verranno presentati gli algoritmi di controllo e recupero di errore che abbiamo impiegato. Verranno poi illustrati dei diagrammi di flusso che spiegano la concatenazione delle varie azioni sia nel moderatore che negli ascoltatori. Accenniamo già da adesso che la comunicazione e lo scambio dei messaggi avviene in modo asincrono e casuale al fine di evitare una implosione di richieste di ritrasmissione, nel caso di perdità di qualche pacchetto, verso il moderatore; tale meccanismo si è ispirato alla filosofia SRM (Scalable Reliable Multicast).

Anche le richieste di ritrasmissione sono basate su un meccanismo che trae a sua ispirazione da SRM, in quanto non vengono immediatamente inviate quando l'applicazione rileva una perdita, ma si attende lo scadere di un timer; se mentre il timer è ancora in esecuzione arrivano richieste di ritrasmissione identiche a quelle che stiamo per fare annulliamo le richieste che siamo in procinto di fare.

L'interfaccia grafica è invece stata realizzata in Tcl/Tk e si è cercato di rendela il più possibile “comprensibile”, ovvero ad ogni azione intrapresa dall'applicazione si è cercato di associare un messaggio di notifica che renda consapevole l'utente di cosa sta accadendo.

34




Page hosted at Laboratorio Telematico at Info-Com
Last Update ven gen 31 18:03:32 CET 2003