Componenti di RendezVous: RV, RVD, RVA, RVCache

Le componenti di RendezVous sono:

-RVD (RendezVous Daemon)

-RVRD (RendezVous Routing Daemon)

-RVA (RendezVous Agent)

-RVCache (RendezVous Cache)

RVD (demone Rendezvous) vs RVRD (demone di routing Rendezvous)
RVRD (Rendezvous Routing Daemon) sono semplicemente processi di proprietà di middleware o team di rete che ascoltano il traffico multicast localmente e lo trasmettono a un’altra controparte RVRD (un altro host) utilizzando TCP. Questo host remoto reindirizza questo traffico alla propria rete. Quindi essenzialmente utilizzava il bridge tra due diverse reti regionali, ad es. Londra e Newyork ecc.

RVRD è multicast da un lato e unicast dall’altro, quindi riceve messaggi da più RVD (Demone Rendezvous) e invia tramite TCP a un altro RVRD che distribuisce messaggi su RVD diversi (Demone Rendezvous) sulla propria rete, ad es. dire sulla rete di New York. Il controllo di RVRD (Rendezvous Routing Daemon) risiede nel team di middleware / rete e decidono quali argomenti / soggetti sono consentiti per il traffico RVRD (Rendezvous Routing Daemon). Quindi, se si invia un messaggio su un argomento che non è configurato su RVRD e l’abbonato per quel servizio si trova su un’altra rete fisica, non riceverà quei messaggi fino a quando tale argomento non sarà abilitato sul fronte RVRD (Rendezvous Routing Daemon).

D’altra parte RVD (Rendezvous Daemon) è un processo in background che viene eseguito su ogni host che desidera inviare o ricevere messaggi dalla rete tibco multicast. Il processo dipende da questo per una comunicazione di rete affidabile ed efficiente. tutti i messaggi passano via rvd prima che entrino o lascino l’host su una rete multicast e RVD (Rendezvous Daemon) è responsabile della creazione di pacchetti o dell’assemblaggio di pacchetti da e verso la rete.

Socket client Daemon:
Il demone Rendezvous (rvd) e il demone di routing Rendezvous (rvrd) aprono entrambi un socket client per stabilire una comunicazione con i loro client (programmi Rendezvous). L’opzione -listen su rvd e rvrd consente di specificare dove il demone dovrebbe ascoltare le nuove connessioni client. Al
contrario, i programmi Rendezvous richiedono connessioni con il demone su quel socket client. Il parametro daemon della funzione di creazione del trasporto determina come e dove trovare il demone Rendezvous e stabilire la comunicazione.

Ogni oggetto di trasporto stabilisce un condotto di comunicazione con un demone Rendezvous, come descritto in questi passaggi:

1. Il processo daemon apre un socket client (TCP) e attende che un client richieda una connessione. L’opzione -listen del demone Rendezvous specifica dove il demone è in ascolto per i nuovi trasporti client.
2. Il programma chiama la funzione di creazione del trasporto, che contatta il demone sul socket client specificato nel suo parametro daemon. Il parametro daemon della funzione di creazione del trasporto deve corrispondere all’opzione -listen del processo daemon; cioè, devono specificare lo stesso tipo di comunicazione e lo stesso numero di socket.

Se nessun processo daemon è in ascolto sul socket client specificato, la chiamata di creazione del trasporto avvia automaticamente un nuovo processo daemon (che è in ascolto sul socket client specificato) e quindi tenta di connettersi ad esso.

3. Il processo daemon apre un canale per la comunicazione privata con il nuovo trasporto. Tutte le comunicazioni future utilizzano quel condotto privato. Il socket della richiesta è ora gratuito per richieste aggiuntive da altri trasporti client.

Sui punti
– RVD trasmette il messaggio in uscita dal programma alla rete.
– RVD recapita il messaggio in entrata dalla rete al processo.
– RVD si occupa delle specifiche del sistema operativo e incapsula coloro che lasciano il processo indipendente da dettagli di così basso livello.
– Il demone RVD può essere avviato automaticamente se non è già in esecuzione, potrebbe uscire dopo un determinato periodo di inattività.

RVA – RendezVous Agent:

Un TIBCO Rendezvous agent comunica con un demone TIBCO Rendezvous in esecuzione nell’ambiente del server delle applicazioni. Il demone ascolta i messaggi su un flusso di messaggi TIBCO Rendezvous.

Quando il daemon trova un messaggio richiesto da una delle tabelle TIBCO Rendezvous (consultare le tabelle TIBCO Rendezvous), recupera i dati del messaggio e lo passa alla tabella tramite l’agente. Una tabella del flusso di dati per TIBCO Rendezvous riceve i messaggi da un’applicazione aziendale attraverso un flusso di messaggi TIBCO Rendezvous.

Ogni messaggio è identificato per soggetto e ogni nuovo messaggio per un oggetto è un nuovo evento. Quando la tabella riceve un nuovo messaggio, in primo luogo mappa i dati del messaggio nei tipi di dati per la tabella del flusso di dati. Si hanno delle limitazioni e cioe’ tutti i messaggi per un oggetto evento devono essere nella stessa forma: ogni messaggio deve avere gli stessi campi, sebbene un campo possa essere vuoto. Inoltre, alcuni tipi di dati TIBCO Rendezvous non sono supportati e non possono essere mappati in una tabella del flusso di dati.

I TIBCO Rendezvous agent sono asincroni e ricevono messaggi di evento quando si verificano gli eventi, come mostrato nella tabella seguente. Non è possibile recuperare i dati della tabella di ricerca da un agente TIBCO Rendezvous.

Obiettivo

L’obiettivo del routing del software daemon è quello di prendere i messaggi Rendezvous da una rete e renderli disponibili su altre reti. L’effetto è di connettere un set di reti in una rete più ampia. Confronta questo obiettivo con l’obiettivo di instradare l’hardware: prendere i pacchetti da una rete e renderli disponibili su altre reti. Ancora una volta, l’effetto è di connettere un insieme di reti in una rete più grande.

Connessioni

Il software demone di routing utilizza una tabella di routing per definire le connessioni alle reti locali e ad altri daemon di routing. Confronta questo strumento con un router hardware, che utilizza una tabella di routing per definire le connessioni tra il router e le sue interfacce. Ogni voce nella tabella di routing descrive un demone di routing e le sue connessioni.
Sebbene ogni daemon di routing specifichi solo la propria voce della tabella di routing, tutti i daemon di routing in una WAN cooperano per condividere queste informazioni, in modo che ogni daemon di routing costruisca una copia della tabella di routing globale completa.

Rete locale

Un demone di routing serve un set di reti locali inoltrando i messaggi tra tali reti e altre reti (di solito, tramite altri demoni di routing). Mentre l’hardware di routing specifica le sue reti locali principalmente in termini di interfacce di rete, il software daemon di routing specifica ciascuna rete locale come coppia combinando rete e servizio UDP o PGM. I servizi UDP o PGM dividono efficacemente la rete fisica in reti logiche separate, anche se utilizzano lo stesso hardware..

Un demone di routing filtra i messaggi in base al nome dell’oggetto, limitando gli oggetti che le reti locali possono importare ed esportare. Il filtraggio dei messaggi per argomento nel software del demone di routing produce una granularità più fine di controllo rispetto al filtraggio dei pacchetti in un router hardware. I daemon di routing controllano l’insieme di argomenti che ciascuna rete può esportare su altre reti e importare da altre reti.

Voce della tabella di routing

Le voci della tabella di routing sono gli elementi di base di un sistema di routing Rendezvous. Nella maggior parte dei casi, ogni processo del daemon di routing incarna una singola voce della tabella di routing, che indica quel demone in tutta la WAN e ne descrive il funzionamento.
In rare situazioni, un processo del demone di routing può incarnare più tableentries di routing. Ogni voce definisce un router software separato e indipendente, ma senza i costi associati alla commutazione di processo. Per ulteriori informazioni, consultare Voci della tabella di routing indipendenti in un unico processo a pagina 96. La combinazione di tutte le voci della tabella di routing di tutti i daemon di routing produce la tabella di routing globale. Ogni daemon di routing utilizza la sua copia della tabella di routing globale
per inoltrare i messaggi in modo efficiente ad altri demoni di routing e alle loro reti.

Nome del router

Ogni voce della tabella di routing ha un nome. I daemon di routing utilizzano questi nomi per identificarsi l’un l’altro, quindi i nomi devono essere univoci nell’intera WAN. Un modo conveniente per garantire nomi univoci è utilizzare i nomi DNS completi dei computer host rvrd; ad esempio, frobitz.yellowNet.baz.com. (Quando un processo include diverse voci della tabella di routing, è possibile utilizzare un prefisso per creare nomi univoci, ad esempio 1.frobitz.yellowNet.baz.com). Altre convenzioni di denominazione sono accettabili, purché i nomi siano univoci.
Il nome è una stringa di caratteri alfanumerici, punti e trattini. La lunghezza totale massima della stringa è di 64 caratteri (inclusi i separatori di punti).

– / 5

Grazie per aver votato!