SCALA MONDIALE 55

Figura 6.15: Devianza standard su scala planetaria

56 CAPITOLO 6. RISULTATI DEI TEST

Figura 6.17: Perdite di eventi su scala planetaria, fino a 8192 byte

6.4. FRAMMENTAZIONE 57

6.4 Frammentazione

Prendendo in esame un singolo subscriber, facendo variare la frammentazione utiliz-zando l’opzione -fragSize, quello che si ottiene `e in figura 6.19.

Figura 6.19: Perdita di eventi al variare del parametro fragSize

Quello che appare `e che la frammentazione non incide sul comportamento a “gra-dino”: esso si presenta nello stesso punto indipendentemente dalla dimensione scelta per i frammenti del middleware. La causa allora `e da ricondurre a livelli della pila protocollare pi`u bassi, UDP o IP per esempio. Nei prossimi paragrafi si vedr`a, tramite incrementi pi`u piccoli, cosa accade tra gli estremi del “salto”.

6.5 In dettaglio

Come `e apparso nei paragrafi precedenti esiste una sorta di “soglia”. Si vuole ora analizzare il comportamento in maggior dettaglio, nell’intervallo 8kbytes 16kbytes. A tale scopo il programma di test `e stato opportunamente modificato, con l’inserimento del parametro stepSize che consente di incrementare gradualmente la dimensione degli eventi. In questo modo `e possibile vedere l’andamento con scalini pi`u ravvicinati. Si prende in considerazione solo il caso Best-Effort, in quanto le perdite che si verificano

58 CAPITOLO 6. RISULTATI DEI TEST

sono causa dell’aumento della latenza in Reliable, percui `e sufficiente monitorare il comportamento degli eventi persi

Figura 6.20: Perdite in best-effort con incrementi di 1024 byte

Figura 6.21: Perdite in best-effort con incrementi di 512 byte

Come si pu`o notare, continua ad essere presente un repentino aumento delle per-dite, nonostante non sia proprio sugli 8k ma spostato intorno ai 14k. La situazione si distingue nettamente in figura 6.21.

Capitolo 7

Conclusioni

Il Middleware lavora egregiamente fino ad una dimensione di 8192 byte. Andando a vedere nel dettaglio, anzich´e passare direttamente da 8192 a 16384, si sono condotti dei test per esaminare quanto la soglia possa essere spostata verso i 16k. Incrementando gradualmente la dimensione di 1024 byte alla volta la soglia viene a trovarsi tra 13312 e 14336 byte. Agendo sulla dimensione dei frammenti, quando la frammentazione si fa necessaria, non `e possibile ottenere vantaggi in termini di drop rate: anche varian-dola, il comportamento continua a presentare la soglia di cui sopra. In effetti, nella specifica e nell’implementazione non esiste una particolare entit`a che si debba occupare della gestione dei frammenti, essa `e stata implementata dal team di RTI come una feature dell’entit`a FlowController e l’unico parametro inerente ad essa che ci consente di manipolare `e bytes for token. Esso stabilisce il numero massimo di bytes che pu`o essere inviato con ogni token1, inoltre non c’`e una corrispondenza diretta tra esso e la dimensione dei frammenti. Essa infatti pu`o essere:

a) Bytes for token;

b) Il minimo tra le dimensioni massime di pacchetto consentite tra tutti i protocolli di transport installati con il DataWriter.

Usando UDP dovremmo avere una dimensione di pacchetto massima consentita pari a 64kbyte. Ma solo un’analisi pi`u approfondita con un tool come ethereal/wireshark pu`o confermare quale delle due dimensioni sia presa per i frammenti. Eseguendo delle tornate su una LAN composta esclusivamente da tre nodi, si `e verificato che questo effetto a gradino si presenta solo sui test condotti su PlanetLab, per cui `e molto pro-babile che sia dovuto alle configurazioni dei nodi e/o degli apparati di rete che i dati attraversano da mittente a destinatario.

Con delle difficolt`a ad una velocit`a di 100 eventi al secondo e dimensioni abbastanza sostenute, il sistema pu`o ritenersi adatto ad applicazioni orientate agli eventi in cui modeste quantit`a di dati vengono scambiate a velocit`a variabili ed anche molto elevate.

1durante i test `e stato usato il flowcontroller di default che ha un numero di token illimitati

60 CAPITOLO 7. CONCLUSIONI

Per quanto riguarda le grandi quantit`a di dati, `e verosimile che non vi sia necessit`a di un invio cos`ı frequente, tuttavia anche a basse velocit`a possono verificarsi dei problemi per dimensioni dei dati tra 32Kbyte e 128Kbyte.

Ad influenzare i test ci sono state delle limitazioni di banda imposte dal PlanetLab

Monitor : poich`e la distribuzione delle risorse tra gli utenti deve essere equa, quando

uno di essi ne consuma troppe viene limitato, implicando, nel nostro caso, un invio pi`u lento dei dati. Se tale limitazione avviene al nodo che funge da Publisher tutto il test ne risentir`a. A questo proposito il programma di test prevede la possibilit`a di impostare delle pause tra un test e l’altro: con una pausa di 10 minuti tra il test di una taglia e la successiva si scongiura tale effetto, anche se esso dipende non solo dalla dimensione dei dati trasmessi e dalla velocit`a, ma anche dal numero dei nodi in gioco e dal numero dei campioni che si intendono inviare per ricavare le statistiche. Infatti dovendo utilizzare connessioni unicast perch´e, come detto, il multicast non `e adatto, quando si trasmettono 128KByte al secondo a 20 nodi, si stanno in realt`a trasmettendo ben 2MByte al secondo da un singolo nodo.

Per quanto riguarda la scrittura del programma di test bisogna dire che le API sono abbastanza semplici, con uno studio della specifica DDS e dello user’s manual fornito con RTI DDS `e stato possibile scrivere l’intero programma agevolmente. La documentazione delle API non `e molto chiara, ma attenendosi allo Standard `e di facile utilizzo, eccezion fatta per le estensioni apportate. Le estensioni, non essendo presenti sullo standard, rimangono comunque un po’ oscure: alcune sono per`o spiegate sullo

user’s manual che fornisce anche degli esempi di utilizzo.

Infine, RTI non ha necessit`a di essere presente sui nodi: in fase di compilazione include tutto il necessario all’interno degli eseguibili del test. Per cui `e sufficiente cari-care RTI DDS su una macchina, sviluppare il software su di essa, compilare utilizzando il giusto compilatore e librerie, distribuire i binari ottenuti ai nodi che si intende far partecipare alla comunicazione. Se da un lato questa `e una caratteristica positiva, in quanto evita di installare software specifico sui nodi, dall’altro implica per`o che due di-verse applicazioni residenti sullo stesso nodo, avranno entrambe una replica del codice del middleware come schematizzato in figura 7.1.

61

Figura 7.1: Vista di un nodo sul quale girano contemporaneamente due applicazioni RTI DDS

Bibliografia

[1] Sistemi Operativi, A. Silberschatz, P.B. Galvin, G. Gagne;

[2] Distributed Event Routing in Publish/Subscribe Communication Systems, R. Baldoni, A. Virgillito;

[3] Exploiting IP multicast in content-based publish-subscribe systems., Opyrchal L., Astley M., Auerbach J.S., Banavar G., Strom R.E., Sturman D.C.;

[4] Survey of publish/subscribe event systems., Liu Y., Plale B.;

[5] Peer-to-peer overlay broker networks in an event-based middleware., Pietzuch P., Bacon J.;

[6] On the modelling of publish/subscribe communication systems. Concurrency and

Computation: Practice and Experience, Baldoni R., Beraldi R., Piergiovanni S.T.,

Virgillito A;

[7] Achieving scalability and throughput in a publish/subscribe system, Team T.G.; [8] Evaluating the Performance of Publish/Subscribe Platforms for Information

Mana-gement in Distributed Real-time and Embedded Systems, Ming Xiong, Jeff Parsons,

James Edmondson, Hieu Nguyen, and Douglas C Schmidt; [9] RTI User’s Manual, http://www.rti.com;

[10] PlanetLab User’s Guide, http://www.planet-lab.org;

[11] Data Distribution Service for Real-Time Systems Specification,

http://www.omg.org;

[12] Ethereal network protocol analyzer for Unix and Windows,

http://www.ethereal.com;