DDS: affidabilità e architettura
Per quanto riguarda l'affidabilità il trasporto può essere Best Effort o Reliable (affidabile). Nel primo caso non viene fornita alcuna garanzia che i dati vengono consegnati, né ai subscribers viene garantito un certo livello di qualità del servizio, ma tutti ottengono una bitrate e un tempo di consegna variabile. I dati sono inviati senza risposta; publishers e subscribers obbediscono alle impostazioni della politica QoS Deadline. Il controllo della banda è gestito utilizzando la politica QoS Time Based Filtering. Nel secondo caso invece viene garantita la consegna ordinata. Il publisher utilizza la politica QoS History per tenere traccia dei dati inviati. Non è possibile avere lo stesso livello di affidabilità e di determinismo. Si può utilizzare la modalità Best Effort per lo streaming di dati così non sia il re - invio dei pacchetti persi e si ottimizza la latenza. Si può invece utilizzare la modalità Reliable per i comandi e gli eventi; si re - inviano i pacchetti persi fino ad un timeout; i pacchetti vengono ricevuti nell'ordine corretto e si ha un meccanismo speculativo per la cache.
Figura 4: consegna Best - Effort
Figura 5: consegna affidabile
In generale esistono tre implementazioni di DDS:
- Architettura Decentralizzata: su ogni nodo ci sono dei threads embedded che gestiscono la comunicazione, l'affidabilità, QoS, etc. Vantaggi: gli end - points della comunicazione sono self - contained e non c'è overhead causato da daemons esterni. Svantaggi: il processo utente è più complesso (ad esempio i dettagli della configurazione, come il multicast, e i processi di discovery, devono essere gestiti).
Figura 6
- Architettura Federated: su ogni nodo c'è un daemon separato che gestisce la comunicazione, l'affidabilità, QoS, etc. Vantaggi: minore complessità del processo utente e, potenzialmente, maggiore scalabilità per un più grande numero di subscribers. Svantaggi: punti di configurazione/failure addizionali e overhead dovuto alla comunicazione tra processi.
Figura 7
- Architettura Centralizzata: un singolo processo daemon per l'intero dominio. C'è un nodo su cui esso è in esecuzione. Il vantaggio è che il setup del daemon è semplice. Svantaggi: single - point - of - failure e problemi di scalabilità.
Figura 8
Pagine totali: 3 - 1 2 3
Inserisci un commento
(solo il nome è obbligatorio; tutti gli altri campi sono facoltativi)
Pagine di commenti: 0
|
