Publish/Subscribe Communication Infrastructures. Esercizi M I D L A B. Sistemi Distribuiti Leonardo Querzoni - 20/3/2007

Transcript

1 M I D L A B M i d d l ew a re L a b o r a t o r y Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica Publish/Subscribe Communication Infrastructures Esercizi Sistemi Distribuiti Leonardo Querzoni - 20/3/2007

2 Si consideri il seguente sistema publish/subscribe realizzato tramite il protocollo SIENA. P I 9 G H F A E B 6 C 4 5 D L event space è costituito da un unico attributo numerico x che può assumere valori reali. Sono disponibili gli operatori <=>. Esercizio

3 I subscribers hanno inserito le seguenti sottoscrizioni. Subscriber Subscription A x>23 B x<0 OR x>90 C x<40 D x>25 AND x<60 E x>5 AND x<8 F x>5 AND x<0 G x>5 AND x<20 H x<2 I x>50 Indica modifiche apportate rispetto alla versione precedente Dopo aver definito uno spanning tree associato al broker su cui si attesta il publisher P, calcolare la content-based forwarding table esatta relativa al suddetto albero per ogni broker. Infine calcolare il percorso seguito dall evento x=6 all interno dell ENS. Esercizio

4 Per prima cosa definiamo uno spanning tree associato al broker Un qualsiasi albero passante per tutti gli altri broker va bene. P I 9 G H F A E B 6 C 4 5 D Esercizio

5 Il contenuto delle subscription tables viene calcolato partendo dai subscriber e risalendo l albero fino alla radice (broker ) Broker Interface Content-based address 2 x>50 3 x>23 OR (x<0 OR x>90) OR x<40 OR (x>25 AND x<60) 2 7 x> x>23 OR (x<0 OR x>90) 3 8 x<40 OR (x>25 AND x<60) 4 5 x>23 OR (x<0 OR x>90) 5 6 x>23 OR (x<0 OR x>90) 8 0 x<2 OR (x>5 AND x<20) 8 x>5 AND x<0 8 2 x<40 OR (x>5 AND x<8) OR (x>25 AND x<60) 0 9 x<2 OR (x>5 AND x<20) 3 x>5 AND x<0 2 4 (x>5 AND x<8) OR (x>25 AND x<60) 4 5 (x>5 AND x<8) OR (x>25 AND x<60) Facciamo riferimento ad una situazione a runtime quando si suppone che, indipendentemente dall ordine di inserimento delle sottoscrizioni, il sistema abbia ripulito le tavole. Esercizio

6 Routing dell evento x=6. Subscribers notificati: C, E, G. Sono sottolineate le righe delle tavole i cui indirizzi sono soddisfatti dall evento Broker Interface Content-based address 2 x>50 3 x>23 OR (x<0 OR x>90) OR x<40 OR (x>25 AND x<60) 2 7 x> x>23 OR (x<0 OR x>90) 3 8 x<40 OR (x>25 AND x<60) 4 5 x>23 OR (x<0 OR x>90) 5 6 x>23 OR (x<0 OR x>90) 8 0 x<2 OR (x>5 AND x<20) 8 x>5 AND x<0 8 2 x<40 OR (x>5 AND x<8) OR (x>25 AND x<60) 0 9 x<2 OR (x>5 AND x<20) 3 x>5 AND x<0 2 4 (x>5 AND x<8) OR (x>25 AND x<60) 4 5 (x>5 AND x<8) OR (x>25 AND x<60) Esercizio

7 Sul grafo: P 2 7 I 9 H 3 G F A E B 6 C 4 5 D Esercizio

8 Riporto qui di seguito alcune domande e relative risposte che mi sono arrivate via . Domanda: non è possibile fare un'unione delle condizioni nelle routing table? Ad esempio nel broker 3 interface 4 non sarebbe possibile porre un'unica condizione del tipo ( x<0 AND x>23)? Oppure broker 8 interface 2 (x<60 ) Risposta: In teoria si potrebbe fare in quanto il routing dei successivi eventi sarebbe comunque corretto. Nella pratica però l'algoritmo non prevede questa possibilità: sottoscrizioni che non si "ricoprono" completamente vengono trattate come sottoscrizioni disgiunte. Inoltre, in un caso come questo, l'aggiornamento delle sottoscrizioni andrebbe comunque propagato, quindi non avresti alcun risparmio in termini di messaggi (cosa che hai invece nel caso di totale copertura tra sottoscrizioni). Domanda: ed eventualmente nel broker 2 interface 4 (x>5 AND x<8)or(x>25 AND x<60)? Risposta: Qui invece non capisco cosa potresti cambiare... le due condizioni in OR sono completamente disgiunte... Domanda: I valori indicati nell'esercitazione non corrispondono con quelli trovati da me. Forse ci potrebbe essere qualche errore. Potrebbe gentilmente visionarli e, possibilmente, illustrarmi il corretto procedimento? broker3->int 8 x<60 Risposta: In questo caso il valore da te indicato non è concettualmente sbagliato, ma presuppone che l'algoritmo di SIENA sia in grado di prendere più sottoscrizioni diverse e "costruire" una nuova sottoscrizione che rappresenti l'unione "intelligente" delle precedenti (cioè in cui sottoscrizioni "contigue" vengono trasformate in un'unica sottoscrizione. es: <x<5 OR 4<x<0 diventa <x<0). Questo in linea di principio non è vero (nel senso che l'algoritmo proposto non fa questo tipo di ragionamento. Controlla sull'articolo originale per conferma). In questo caso quindi scrivere x<60, per quanto impreciso, non è da considerare un vero e proprio errore, in quanto non pregiudica il corretto funzionamento del sistema (cioè non provoca notifiche di eventi errate o mancanti). Esercizio

9 Domanda: b8->int 2 x<40 or x>5 and x<8 or x>25 and x<60 Risposta: Qui hai ragione. Il fatto che la sottoscrizione di C copra la sottoscrizione di E è una cosa di cui si può rendere conto solo il broker 8 e non il 2 come la tavola che ho riportato farebbe pensare. Questa sera aggiorno di conseguenza la soluzione. Nota comunque come anche in questo caso l errore non pregiudichi il corretto funzionamento del sistema di instradamento degli eventi. Domanda: In ultimo, è possibile che la subscription del subscriber B (x<0 and x>90) non porti mai a avere un match su un evento, violando così la proprietà di liveness? Risposta: Qui ci sono due cose da dire. La sottoscrizione di B è sbagliata. Deve essere (x<0 OR x>90), altrimenti non avrebbe senso perché, come tu dici, non sarebbe mai verificata. Detto questo, io non ho mai parlato di proprietà di liveness per questi sistemi. SIENA e SCRIBE offrono servizi di tipo "best-effort", cioè non garantiscono che il sistema necessariamente funzioni in modo perfetto o faccia qualcosa di utile. Ciò non toglie che, nella maggior parte dei casi reali, essi funzionino bene. E' un po' quello che succede con la maggior parte delle applicazioni su Internet: il loro funzionamento non è garantito, ma ciononostante di solito funzionano bene. D'altra parte, anche solo esprimere una proprietà di liveness per un sistema come SIENA, non è affatto banale. Alcuni ricercatori hanno tentato di esprimere la correttezza dei sistemi publish/subscribe tramite proprietà di tipo safety e liveness, ma a tutt'oggi non c'è un vero e proprio "accordo" sulla loro capacità di cogliere tutti gli aspetti di un sistema così complesso. Domanda: Inoltre non mi è chiaro il perché dell'indirizzo ANY in b->int3. Risposta: Ho indicato ANY per brevità. Il content address completo sarebbe: x>23 OR (x<0 OR x>90) OR x<40 OR (x>25 AND x<60) E' chiaro che le due condizioni x>23 e x<40 poste in OR assicurano che qualsiasi evento prodotto dovrà essere inviato dal broker sull'interfaccia 3. Questo è il motivo per cui è stato indicato ANY, ma devo dire che, per precisione (esattamente per lo stesso motivo indicato nella risposta alla tua prima domanda), sarebbe più correto indicare la sottoscrizione completa. Esercizio