E’ un processo in background che supporta tutte le comunicazione sul bus TIBCO
Su ogni macchina sarà presente almeno un’istanza del Daemon per lo scambio di messaggi sul BUS
In particolare TIB/Rendezvous Daemon serve a:
-Instradare i messaggi
-Consegnare i messaggi in modo affidabile
-Filtrare i messaggi in base al Subject associato
TIB/Rendezvous Daemon utilizza due protocolli di comunicazione:
-TCP/IP (Transmission Control Protocol/Internet Protocol)
-UDP (User Datagram Protocol)
Le applicazioni RV (Adapter o API RV):
-Si connettono al RVD attraverso la connessione TCP/IP
-La porta di riferimento per la connessione è configurabile di solito è usata la porta di default 7500
RVD comunica con le altre applicazioni sulla rete (BUS TIBCO) utilizzando un servizio UDP in quanto:
-I programmi trasmettono piccole quantità di dati contemporaneamente
-C’è necessità di trasferimenti in tempo reale
Il servizio RVD:
Divide la rete in partizioni logiche (ogni applicazione comunica attraverso un singolo servizio e può comunicare solo con applicazioni che utilizzano lo stesso servizio) è definito da un Service Number (concide con una porta UDP) e da un indirizzo IP Multicast. RVD implementa inoltre, in maniera trasparente, il protocollo TRDP (TIB Reliable Data Protocol), per l’affidabilità del delivery dei messaggi effettuando:
-L’indirizzamento su base Subject dei messaggi
-Il delivery sequenziale dei messaggi
-La ritrasmissione dei messaggi persi all’interno di una finestra di ritrasmissione (default a 60 secondi).
Il RVD non usa file di configurazione e si basa sui parametri di network definiti dalle singole applicazioni quando stabiliscono una sessione RV.
L’inizializzazione di una Sessione RV avviene valorizzando i seguenti parametri di rete:
-daemon (specifica quale IP address e quale porta usare quando l’applicazione si connette al RVD. I valori di default sono localhost, porta 7500)
-service (specifica la porta UDP usata dal RVD per inviare pacchetti sulla rete. La porta di default è 7500)
-network (specifica l’interfaccia e gli indirizzi IP multicast da usare nella pubblicazione dei messaggi ed eventualmente gli IP address multicast addizionali per l’ascolto. Vuoto di default.)
Di solito, per questi parametri (daemon, service e network), vengono utilizzati i valori di default, comunque la necessità di una loro diversa valorizzazione è legata al verificarsi di una o più condizioni.
Daemon parameter:
Un’applicazione gira su una macchina ma si connette con un RVD istanziato su una macchina diversa
Service parameter:
Applicazioni diverse girano sulla stessa rete e si ha la necessità di isolarle tra loro
Alcune applicazioni utilizzano un RVRD per comunicare con applicazioni distribuite su reti diverse e con le quali devono condividere un certo service group
Network parameter:
Le applicazioni RV girano su macchine con più di una scheda di rete e deve quindi essere specificata l’interfaccia utilizzata dalle comunicazioni RV
Macchine sulla rete utilizzano indirizzamento multicast e le applicazioni devono specificare un set di indirizzi al quale registrarsi
ATTENZIONE!!!
Startare più di un Daemon su un computer non produce alcun beneficio, e può provocare errori o inefficienza.
TIB/Rendezvous Routing Daemon (RVRD):
E’ necessario nel caso in cui i messaggi devono attraversare reti diverse, RVRD infatti disaccoppia il processo di comunicazione dagli address internetwork
I messaggi in questo modo vedono le diverse reti come una sola. Il tutto in maniera trasparente per il codice applicativo. Deve essere naturalmente configurato adeguatamente ogni RVRD
In particolare il RVRD deve essere previsto quando:
-le networks interessate risiedono in aree geografiche distanti
-le networks interessate pur risiedendo in aree geografiche vicine non sono connesse da router che supportano il multicast
-le networks interessate sono separate da un firewall
i messaggi devono attraversare link WAN lenti o in generale quando le networks interessate hanno velocità differenti
In tutti questi casi su ogni network deve essere attiva un’instanza RVRD. Ogni istanza può interagire con uno o più RVRD attigui (neighbor) con i quali possono essere scambiati i messaggi. RendezVous Agent (RVA) è un processo in background che supporta comunicazioni Rendezvous per applet Java. Per ragioni di sicurezza, applet remote non possono connettere direttamente al daemon ma solo tramite RVA.
Le principali caratteristiche di RVA sono:
protegge il daemon da richieste improprie. Si comporta come barriera di sicurezza, proteggendo la rete da interferenze applet remote non possono avviare un processo RVA ma devono connettersi ad un processo già attivo
RVCache memorizza i dati delle comunicazioni più recenti filtrate attraverso i subject e automaticamente spedisce tali dati ai nuovi listener che a mano a mano si collegano.
Coordinamento Messaggistica
Il tipo di coordinazione più semplice tra processi viene realizzato attraverso l’invio di Messaggi da un componente ad un altro.Dal punto di vista applicativo un Messaggio è inviato e l’applicazione assume che esso sia stato consegnato. Se poi il Messaggio viene ricevuto o meno dipende dalla qualità utilizzata per il servizio.
TIBCO QoS (Quality of Service):
-Reliable
-Certified
In modalità Reliable ogni messaggio:
Sarà presente sulla rete esattamente una sola volta, indipendentemente dal numero di applicazioni che sono in ascolto per quel messaggio
Non vi sono messaggi di acknowledgement
La modalità Certified Message (CM) permette di rendere sicura la consegna dei messaggi RV sul protocollo UDP attraverso:
Certezza
Controllo
Ritrasmissione
Registrazione
Notifiche
Certezza: La certezza della consegna è determinata dal fatto che ciascun messaggio viene memorizzato in un file ledger e sarà eliminato solo dopo una conferma da parte del ricevente.
Controllo: I programmi di controllo determinano una scadenza esplicita per ogni messaggio.
Ritrasmissione:Una volta che un programma trasmette un messaggio certificato, il software di TIB/Rendezvous continua i tentativi di consegna fino a che la consegna non riesca, o fino a che si raggiunge la scadenza di messaggio.
Notifiche: TIB/Rendezvous utilizza dei messaggi di notifica per informare i programmi di ogni evento significativo per quanto riguarda la consegna.
Registrazione: TIB/Rendezvous memorizza i messaggi in un registro che può essere su file o in memoria.
Per garantire la corretta ricezione dei messaggi vengono usati dei message ledger (residenti in memoria o su disco) per memorizzare i messaggi prima della trasmissione, e qui tenuti fino al segnale di ackowledgement da parte dei riceventi. Se un Publisher non riceve la conferma della consegna da un trasporto certificato del Subscriber (per esempio, a causa degli impulsi errati della rete), chiede automaticamente la conferma. Quando un Subscriber certificato riceve una richiesta per la conferma, controlla il relativo registro e riconferma la ricezione dei messaggi che ha già confermato. Notiamo che se il ledger risiede in memoria, ha lo stesso ciclo di vita del processo Publisher, quindi se il processo si interrompe, si perdono le informazioni contenute nel ledger; se invece risiede su disco, verrà recuperato al successivo riavvio del processo Publisher. I messaggi CM sono come i messaggi ordinari di TIB/Rendezvous, salvo che includono informazioni supplementari, che i trasporti CM utilizzano per la consegna certificata del messaggio:
il nome corrispondente del trasporto CM
il numero progressivo del messaggio
la scadenza di trasmissione del trasporto CM, dopo di che il programma di trasmissione non rinvia più il messaggio
Due tipi di trasporto possono ricevere messaggi CM:
Un trasporto ordinario: questo ignorerà le informazioni supplementari che distinguono un messaggio CM
Un trasporto CM: questo presenterà le informazioni supplementari alla funzione opportuna per la ricezione certificata del messaggio
Il meccanismo di sincronizzazione tra Publisher e Subscriber in un trasporto CM avviene in tre fasi:
-Discovery
-Registration
-Agreement
Il Discovery si compone di quattro azioni:
Il listner passa il messaggio alla funzione di call-back con il numero di sequenza.
Il listner aggiunge il sender name alla lista dei sender nel ledger file.
Il listner contatta il sender per una richiesta di registrazione.
Il listner invia l’advisory message REGISTRATION.DISCOVERY.
Quando un trasporto di trasmissione di CM riceve una richiesta di Registrazione da un trasporto di ricezione di CM, il mittente accetta automaticamente la richiesta:
Il trasporto del sender registra il destinatario per la consegna certificata nel registro del mittente.
Il trasporto del mittente di CM informa il trasporto di ricezione CM che è stato registrato e accetta la responsabilità della consegna certificata.
Il trasporto del mittente di CM invia REGISTRATION.REQUEST advisory, per annunciare il nuovo ascoltatore registrato al programma di trasmissione.
Quando il trasporto dell’ascoltatore di CM riceve la risposta di accettazione, invia un messaggio REGISTRATION.CERTIFIED advisory.
Agreement tra mittente e destinatario:
Il trasporto del mittente CM è responsabile di registrare ogni messaggio outbound e mantenere il messaggio nel relativo registro fino a che non ricevi la conferma della consegna dall’ascoltatore (o fino alla scadenza dei periodi del messaggio)
il trasporto del destinatario CM è responsabile della conferma della consegna di ogni messaggio.
Nell’uso del Certified Messaging delivery occorre tener presente che quando un certified listener viene attivato comunica sul BUS la sua esistenza (via messaggi RV); se però un certified message Publisher inizia ad inviare messaggi prima dell’avvio del Subscriber, questi messaggi vengono persi, non essendo in ascolto alcun certified listener nel momento della pubblicazione del messaggio. Per evitare tale situazione, i certified publisher possono pre-registrare i certified listener (pre-registered listeners) in modo da conservare i messaggi fino a quando non viene avviato il listener.
