TIBRV: Remote vs Local RVD

Question

Lorsqu'elle est connectée à une DRV locale, une application d'envoi est protégée contre les interruptions du réseau et les méthodes d'envoi de message ne bloquent que le temps nécessaire pour que le message atteigne le processus RVD local. En cas de RVD distante, l'application émettrice n'est plus à l'abri des interruptions du réseau et les méthodes d'envoi de messages bloquent pendant le temps nécessaire pour traverser le réseau pour atteindre le processus RVD distant.

Est-ce que je comprends bien? La documentation est vague concernant les démons distants.

Je suis surtout préoccupé par la fiabilité et la performance du message envoyé du point de vue d'une application d'envoi. Introduire un blocage inutile du côté client en raison de l'envoi d'un message (en particulier un saut de réseau) est un gros non-non dans cette application. La vitesse à laquelle les messages atteignent le consommateur n'est pas de la plus haute importance. Dans cet esprit est un RVD distant hors de question?

Answer 1

Dès que vous traversez une couche deux limites de réseau, vous devez utiliser RVRD (Roundevouz Routing Daemon).

Dans un sous-réseau de diffusion/multidiffusion, une RVD garantit un transport fiable. Le RVD reçoit le message via TCP (généralement un processus local) et le transmet ensuite au réseau. Il détient le message pour les années 60 pour être en mesure de retransmettre à d'autres rvd/rvrd que pour une raison quelconque n'a pas reçu le message. Mais comme vous le décrivez, si vous vous connectez à la RVD avec TCP sur un réseau de couche 3, vous faites en fait le même travail que le RVRD. La RVRD connecte des réseaux de couche 2 séparés en utilisant TCP.

Dans un réseau TIBRV, l'application locale transmet le message au RVD/RVRD sur la machine locale, puis le réseau local RVRD transmet le message aux autres réseaux via TCP, sans bloquer le processus qui a envoyé le message.