Il prototipo multicast

Sfruttando l'esperienza acquisita nella programmazione del prototipo unicast è stato possibile costruire con il minimo sforzo anche un prototipo multicast. Le due applicazioni condividono molte soluzioni e si differenziano ovviamente soprattutto nella modalità di spedizione e ricezione dei pacchetti.

Sulla base di quanto riscontrato nelle prove a cui è stato sottoposto il prototipo unicast, e anche per motivi di semplicità, si è deciso (almeno per il momento) di non sfruttare la scalabilità in precisione, e quindi di supportare unicamente la scalabilità in risoluzione spaziale e temporale.

Le tecniche utilizzate

Le tecniche già viste per il prototipo unicast vengono riproposte anche per il prototipo multicast, quindi anche in questo caso ritroviamo l'utilizzo periodico di una frame intra, l'error concealment e la sincronizzazione. Tuttavia in questo caso la tecnica più importante è senza dubbio la MMG; il modo in cui tale tecnica è stata implementata in questo prototipo è spiegato nel paragrafo seguente.

La tecnica Multiple Multicast Group (MMG)

Il flusso codificato viene diviso in sei diversi layer così come mostrato dalla figura .

Figure: La suddivisione in layer

Le frecce servono per sottolineare in che modo si susseguono le varie operazioni di codifica. I blocchi scuri, che rappresentano i sei layer, racchiudono al loro interno i blocchi di codifica che producono il bit-stream dei vari layer. La situazione si può riassumere quindi in questo modo:

Layer 1:

Frame $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 4 di risoluzione base.

Layer 2:

Frame $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 2 di risoluzione base.

Layer 3:

Frame $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 1 e $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 3 di livello base.

Layer 4:

Frame $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 4 di risoluzione enhanced.

Layer 5:

Frame $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 2 di risoluzione enhanced.

Layer 6:

Frame $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 1 e $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 3 di livello enhanced.

Quindi, ad esempio, sottoscrivendo i layer 1 e 2 si ottiene un flusso a frame rate medio e risoluzione base, oppure sottoscrivendo i layer 1 e 4 si ottiene un flusso a frame rate minimo e a risoluzione enhanced. Tutte le possibili combinazioni sono riportate nella tabella .

Table: Combinazioni possibili dei layer

Layer sottoscritti	Frame Rate	Risoluzione
1	Min	Base
1, 2	Med	Base
1, 2, 3	Max	Base
1, 4	Min	Enhanced
1, 2, 4, 5	Med	Enhanced
1, 2, 3, 4, 5, 6	Max	Enhanced

Volendo sfruttare la scalabilità in precisione si potrebbero affiancare altri sei layer corrispondenti a quelli indicati sopra ma nei quali, ad esempio, vengono utilizzati indici da 4 bit, e l'utente potrebbe scegliere se ricevere da uno o dall'altro gruppo. Questo comporta una crescita notevole nel numero di layer utilizzati (e quindi di gruppi multicast da creare) che in questo modo passa a dodici, e ciò ha contribuito a farci scartare il supporto per la scalabilità in precisione nel prototipo multicast.

Il server crea quindi sei diverse sessioni multicast verso sei diversi end-point (indirizzo multicast - numero di porto), a ciascuna di esse è associato un layer diverso. Solo sul primo di questi sei gruppi però viene attivata la trasmissione delle informazioni SDES opzionali, in quanto trasmetterle su tutti i gruppi risulterebbe ridondante. Dal client si possono scegliere ancora una volta i parametri come il frame rate e la risoluzione spaziale, ma in questo caso, a differenza di quanto avviene con il prototipo unicast, nessuna connessione TCP è stabilita con il server, ma le scelte vengono tradotte nella sottoscrizione dei gruppi multicast opportuni (secondo quanto indicato nella tabella ).

Presso il laboratorio multimediale del CNIT è stato possibile effettuare delle prove molto interessanti sul funzionamento di questo prototipo. Infatti la rete locale di tale laboratorio è in realtà composta da più LAN connesse a livello 3 della pila OSI, cioè da veri e propri router che supportano il multicasting, il protocollo di routing multicast utilizzato è il PIM (Protocol Indipendent Multicast) nella modalità sparse [23]. Il nome deriva dal fatto che PIM non si appoggia a nessun protocollo di routing unicast per svolgere il suo compito (cosa che invece fanno altri protocolli di routing multicast). La gestione dell'inoltro dei pacchetti è in parte centralizzata, è previsto infatti un router particolare, detto Rendezvous Point, al quale arrivano i pacchetti multicast e le richieste di sottoscrizione dei gruppi, esso si occupa inizialmente di inoltrare i flussi dei gruppi multicast verso gli host che ne hanno fatto richiesta. Dopo il transitorio iniziale, quando la situazione si è stabilizzata, è possibile effettuare la commutazione verso il funzionamento non centralizzato, I vari router intermedi vengono istruiti sulle modalità di inoltro e quindi si passa da un approccio center-based ad un approccio group-based.

Figure: Il funzionamento del prototipo multicast

La figura mostra la rete sulla quale si è testato il prototipo multicast. Sull'host DENEB è stato installato il server, mentre sui due host CORCAROLI e ALTAIR È stato installato il client. Su ALTAIR si è deciso di ricevere i primi due gruppi, mentre su CORCAROLI si è deciso di ricevere i gruppi 1, 2, 4, 5. Nel transitorio iniziale si è constatato che il traffico relativo a tutti i gruppi raggiungeva il Rendezvous Point, finito il transitorio però la situazione si presentava come quella di figura . Le linee punteggiate rappresentano il traffico multicast che attraversa il collegamento, accanto ad esse ci sono i valori del tasso medio misurato. Si può vedere chiaramente che il traffico relativo ai gruppi che non sono stati sottoscritti da nessuno (gruppi 3 e 6) non lascia la LAN dove si trova la sorgente, ogni router inoltra su una sua interfaccia di uscita solo il traffico relativo a quei gruppi che sono stati sottoscritti dagli host raggiungibili a partire da essa.

La codifica intraframe periodica

Anche in questo caso periodicamente viene inoltrata una frame con codifica intra, così come per il prototipo unicast queste sono sempre del tipo $\left(\vphantom{ k-1}\right.$k - 1$\left.\vphantom{ k-1}\right)$*4 + 4 con k = 25, 50, 75..., ciò vuol dire che tali frame sono sempre inoltrate sul gruppo 1 (quelle enhanced sul gruppo 4). Si è scelto di operare in questo modo perché il gruppo 1 è l'unico che viene ricevuto in ogni caso (il gruppo 4 è l'unico che viene ricevuto in ogni caso, quando si è scelto la risoluzione enhanced) e quindi raggiunge sicuramente tutti i ricevitori.

La sincronizzazione

Sulla sincronizzazione è il caso di spendere qualche parola in più. Come abbiamo visto questo prototipo utilizza la tecnica MMG, questo vuol dire che i dati arrivano al ricevitore separati su più flussi, però su uno (due, se consideriamo anche le frame enhanced) di questi flussi si trovano le frame con codifica intra (che sono quelle che consentono la sincronizzazione). Una volta ricevuta quindi una frame con il marker bit settato (frame intra) non c'è modo di sapere se le frame che si stanno ricevendo sugli altri flussi sono quelle che effettivamente la dovrebbero seguire, infatti i numeri di sequenza non sono d'aiuto perché ogni flusso è trasportato su di una diversa sessione RTP ed ogni sessione viene inizializzata con un numero di sequenza scelto a caso.

Una possibile soluzione potrebbe essere quella di settare il marker bit delle prime frame, di tutti i layer, che seguono immediatamente quella con codifica intra, tuttavia questo approccio non è molto ``pulito'' in quanto violerebbe la semantica che si è affidata al marker bit (segnare le frame con codifica intra). Per questo motivo con il prototipo multicast al momento è permessa la sincronizzazione solo se si decidere di ricevere unicamente i due (o solo il primo dei due) flussi sui quali sono trasportati le frame intra.

Questo problema è tipico delle applicazioni MMG che d'altra parte, presentano anche altre difficoltà. Ad esempio, ogni diversa sessione sarà caratterizzata da un diverso SSRC mentre tutte avranno lo stesso CNAME, sarà però compito del software usato in ricezione riconoscere che tutte quelle coppie SSRC/CNAME in realtà si riferiscono ad un'unica applicazione e gestirle di conseguenza. Questi motivi hanno spinto diversi ricercatori a richiedere che nella nuova versione del protocollo RTP ci fosse il supporto nativo per le applicazioni multisessione (e quindi in particolare per la tecnica MMG). In particolare la proposta ufficializzata M. Speer e S. McCanne in [21] è stata abbracciata dai progettisti di RTP come si può leggere nell'ultimo Internet Draft di RTP [22] in scadenza per Gennaio 2002.

Error concealment

La tecnica utilizzata è del tutto analoga a quella vista per il prototipo unicast. La differenza sta nel fatto che in questo caso ci sono un massimo di sei diverse sessioni multicast, il controllo sui numeri di sequenza, che nel prototipo unicast veniva fatto in globale, in questo caso viene effettuato su ogni singola sessione, indipendentemente dalle altre. C'è una precisa corrispondenza tra le sessioni e i diversi blocchi di codifica (la figura mostra questa corrispondenza per quanto riguarda la codifica), quindi non c'è il pericolo di decodificare un pacchetto con il blocco di decodifica errato, in questo caso è semplicemente necessario stabilire se c'è stata una perdita o meno.

L'interfaccia grafica

L'interfaccia grafica del prototipo multicast deriva direttamente da quella del prototipo unicast.

Figure: L'interfaccia grafica del prototipo multicast

Confrontando la figura , in cui è mostrata l'interfaccia grafica del client multicast, con la figura , in cui è mostrata l'interfaccia grafica del client unicast, si possono notare le differenze. Innanzitutto si nota la mancanza del menu di selezione del numero di bit, in quanto, come detto più volte, questa funzionalità non viene sfruttata dal prototipo multicast, inoltre si nota l'assenza della casellina in cui inserire l'indirizzo IP del server. Tale indirizzo nel prototipo unicast era utilizzato dal client per creare la connessione TCP con il server ma come abbiamo già detto, nel prototipo multicast non viene creata nessuna connessione TCP, quindi quell'indirizzo è inutile. Alla pressione del tasto Start, il client effettua la sottoscrizione dei gruppi opportuni, scelti in base ai parametri (risoluzione e frame rate) impostati, e si mette in attesa della frame con codifica intra, i led in alto a destra si illuminano rispecchiando lo stato dei gruppi multicast (per gruppi attivi si intende quelli che sono stati sottoscritti).