Strategie di invio e ricezione dei pacchetti

Come accennato in precedenza RAMP adatta le sue strategie di gestione dei pacchetti per soddisfare al meglio i requisiti di comunicazione specificati da una applicazione. Per farlo il sistema effettua una pacchettizzazione a li- vello di middleware in modo da evitare l’invio e la ricezione di un intero messaggio in una singola trasmissione single-hop, in particolare un’applica- zione che utilizza RAMP per comunicare può scegliere tre strategie diverse di invio e ricezione dei pacchetti le quali possono impiegate simultaneamente all’interno della stessa rete spontanea. Queste strategie non sono le uniche possibili, è possibile infatti aggiungerne di ulteriori grazie all’architettura a plug-in del middleware che grazie alla sua estendibilità consente facilmente l’aggiunta di nuovi comportamenti. Le strategie di default che RAMP mette a disposizione sono:

• Nonreliable Bulk Transfer (NBRT). • Reliable Packet Streaming (RPS).

• High Reliable Message Delivery (HRMD).

La strategia NRBT è pensata per comunicazioni ad alte prestazioni e con basso overhead dove l’affidabilità non è un requisito stringente. È ideale in caso di trasferimento di file bulk in un canale di comunicazione a bassa la- tenza e comporta un overhead limitato per i nodi partecipanti. Non conside- rando l’affidabilità come obiettivo principale, in caso di fallimento dovuto ad esempio alla mobilità dei nodi intermedi l’utente è tenuto a iniziare esplicita- mente una nuova comunicazione dato che non è previsto nessun intervento da parte del middleware per far fronte a tale fallimento.

58

Figura 25 - Strategia Non Reliable Bulk Transfer (NRBT).

Quando un’applicazione decide di utilizzare questa strategia, RAMP traspa- rentemente esegue una segmentazione dei pacchetti in parti più piccole, dette chunk, le quali sono inviate da sorgente a destinazione in modo ordinato e concorrente. Normalmente quello che accadrebbe senza l’utilizzo di questa tecnica è un trasferimento hop-by-hop dell’intero messaggio. Questa pacchet- tizzazione che di fatto organizza i chunk in pipeline consente ad un nodo in- termedio di inviare al nodo successivo solo una sequenza ordinata di parti più piccole senza dover attendere l’arrivo di tutti i chunk rimanenti ottenendo performance in termini di latenza più elevate. Inoltre tale strategia si traduce in un’occupazione delle risorse di memoria limitata in quanto ogni nodo in- termedio non deve allocare un buffer di dimensioni significative per ospitare l’intero messaggio ma solo quello necessario a contenere un chunk.

La strategia RPS cerca di far fronte ad eventuali disconnessioni per mezzo di risorse addizionali, seppur limitate, dei nodi partecipanti. Risulta utile in scenari di streaming multimediale, infatti rispetto a NRBT in caso di improv- visa interruzione del percorso corrente è in grado di scoprirne uno nuovo in modo del tutto trasparente. Questa modalità permette di conseguenza di ri- spettare il requisito di affidabilità in caso di variazione limitata della topologia di rete attraverso una gestione automatizzata dei percorsi effettuata a livello di middleware.

59

Figura 26 - Strategia Reliable Packet Streaming (RPS).

Quando un’applicazione utilizza questa strategia, RAMP adotta un ap- proccio distribuito e leggero per inoltrare i pacchetti lungo un nuovo percorso in caso di fallimento di un nodo intermedio. In particolare quando un nodo scopre che la strada utilizzata fino a quel momento non è più percorribile, in completa autonomia e in modo reattivo cerca un nuovo segmento verso la destinazione e una volta trovato inizia a inoltrare i pacchetti in arrivo verso il nuovo percorso. In parallelo, nodo in questione che al momento è l’unico a conoscenza di tale interruzione notifica la sorgente inviandogli il nuovo per- corso da utilizzare in modo che possa utilizzarlo per continuare il trasferi- mento di dati. In caso non venga trovata un’alternativa valida per raggiungere la destinazione, i pacchetti in arrivo verranno scartati. Se comparata con NRBT, RPS introduce un overhead addizionale localizzato ai nodi vicini al fallimento del link solo quando tale fallimento si verifica. L’overhead consi- ste nelle operazioni di scoperta di un nuovo percorso, della sua notifica alla sorgente e di modifica dell’header dei pacchetti attualmente disponibili local- mente affinchè il loro rerouting segua la strada appena trovata. Queste opera- zioni come detto in precedenza vengono effettuate una sola volta solo in caso di caduta di un link, in particolare per quanto riguarda l’ultima sarà tempora- nea fino a quando la sorgente non utilizzerà il nuovo percorso valido.

60

Figura 27 - Strategia High Reliable Message Delivery (HRMD).

La terza strategia, HRMD, ha come obiettivo quello di massimizzare le probabilità di invio di un messaggio verso la sua destinazione anche quando un percorso valido per raggiungerla non è al momento disponibile. Per attuare questa strategia RAMP utilizza il paradigma di Store, Carry e Forward, in particolare quando attiva e non è presente nessuna strada verso la destinazione il nodo intermediario salva temporaneamente in memoria il pacchetto in modo che possa riprovare a inoltrarlo successivamente. A fronte di una mo- difica della topologia dovuta alla mobilità del nodo intermedio che adesso è in visibilità della destinazione oppure alla presenza di un nuovo nodo che ha eliminato la partizione della rete, RAMP può procedere alla consegna traspa- rente del pacchetto attraverso una ritrasmissione effettuata a livello di midd- leware. Queste ritrasmissioni sono effettuate un certo numero di volte al ter- mine delle quali il pacchetto viene scartato.

Se confrontata con le due strategie precedenti, HRMD comporta l’introdu- zione di un overhead aggiuntivo dovuto alla capacità di mantenere in memo- ria centrale i pacchetti da inviare e al calcolo del percorso verso la destina- zione una volta disponibile. Pertanto come modalità di comunicazione risulta ideale per il trasferimento di messaggi di dimensione contenuta e in scenari di emergenza dove i nodi partecipanti sono disposti a collaborare nella con- segna del messaggio mettendo a disposizione una parte anche significativa delle loro risorse.

61