inria.lognet.ds.pon ¶

Attention ce module est différent du module inria.smarttools.ds.pon dans la logique de connexion. Il n'a pas été suffisamment testé.

Principe de connexion et But ¶

La logique de connexion est basé sur la publication des services de sorties des composants. On cherche à publier les services de sorties dans le réseau, plutôt que de publier les composants. Ceci dans le but d'éviter plusieurs appel du service de sortie, dans plusieurs envois dans le réseau.

La logique de connexion est donc inversée et ce PON-Multicast n'utilise pas la méthode connect du conteneur dans le même but que les DS traditionnels. La logique des autres DS est que l'on publie les composants pour la réception de messages et non l'envoi de messages, ce que fait ce PON-Multicast.

Propriétés induites ¶

Cela induit que lorsqu'un composant veut envoyer un message 'a' à tous les composants connectés, son conteneur fera un seul appel receive. A partir de cela, il est possible d'optimiser l'envoi du message 'a' à travers le réseau. L'optimisation du réseau vient dans un premier temps de VirtPipes, puis plus tard de l'Overlay Network en général.

La logique incluse dans le conteneur ne peut pas avoir cette propriété car il fait un appel receive pour chaque composant connecté. Alors, il est impossible de tenter d'optimiser l'envoi dans le réseau.

Etapes ¶

Comme tous les DS il y a deux étapes : La publication et la connexion.

Publication ¶

Lorsque PON-Multicast veut publier un composant dans le réseau, il faut publier ses services de sorties (requis), son cdml dans la DHT.

Pour chaque service de sortie du composant 'A', il créé un composant ayant comme service d'entrée (fourni) le service de sortie, et connecte ce composant qui a comme code métier de sérializer le message et de l'envoyer dans un tuyau virtuel (VirtPipeOutput?).

Par exemple, pour le service de sortie 'a' du composant 'A', un composant ayant comme service d'entrée 'a' écrirera dans un tuyau virtuel de sortie représente seulement le service de sortie 'a' pour le composant 'A'.

Une référence à ce tuyau est publiée dans la DHT comme ceci "Service a du composant A" pointe sur "'UUID' du tuyau qui réprésente le service de sortie 'a' du composant 'A'".

Publier le service a "out" du composant A ==> tuyau virtuel A-a -> VPO-A-a

Creation un composant A-a pour ce service "out" connect (A A-a) avec la mecanisque classique Dans ce A-a la methode recieve ecrit dans le tuyau (on ne sait pas s'il y a un reader).

Connexion ¶

Lorsqu'un composant B cherche à se connecter à A (connectTo(B, A)), il va chercher à connecter ses services d'entrées (fournis) aux services de sorties (requis) de A (compatibles).

Le DS PON-Multicast de B va chercher le CDML de A, pour rappatrier les services de sorties. Pour chaque service de sortie de A, que B possède en entrée, il va chercher le UUID du tuyau où 'A' écrit les messages 'a'. Il va créer un lecteur de ce tuyau, qui va désérialiser le message 'a' et invoquer receive sur B avec ce message.

Ce lecteur du service 'a' de 'A' ouvre un tuyau virtuel d'entrée (VirtPipeInput?) avec comme UUID le tuyau de sortie du service 'a' de 'A', l'enregistre dans son VirtPipesService?. Le VPS de B va publier ce VirtPipeInput? dans la DHT (UUID service 'a' du composant 'A' pointe sur VPS de B). Cet enregistrement rend la connexion des tuyaux effective : car lorsque A invoque 'a', le VPS de A va chercher les VPS à qui doit envoyer le message 'a', dont le VPS de B. La connexion est dynamique, et est modélisé dans la DHT.

Un composant B qui a ce service en "in", connect B A, il creer un reader et l'assoicier au tuyau virtuel (DHT) connect B A on recupere le CDML de A et l'instance. on recupere dans DHT les tuyau virtuelle asssocier aux service "out" de B. on publier ds la DHT les tuyaux virtuelles pour les services "in" de A compatible avec les services "out" de B

Conclusion & Discussion ¶

Son principal but est de limiter le nombre d'envoi de message lors de l'invocation de service où aucun destinataire n'est précisé. Dans ce cas précis, SmartTools fait N appels receive aux N composants connectés au service fourni, ce qui entraîne plusieurs envois du même message dans le réseau.

Afin de résoudre ce problème, une nouvelle mécanique de connexion est nécessaire : on ne connecte plus les composants à d'autres composants ou proxies, mais les services de sortie un à un.

Le problème est que cela n'est pas complet. En effet, cela perturbe l'envoi en unicast car il ne faut plus connecter les composants à d'autres composants. Il faudrait donc 2 modèles de connexion à la sortie, un (existant) pour l'unicast, et un autre (nouveau) pour le multicast. Ce sera plus clair si c'était fait comme cela.

Mais actuellement, la logique actuelle permet de faire de l'unicast et du multicast, mais avec plusieurs envoi de messages (d'où un problème de performance).

En tant que prototype, inria.lognet.ds.pon, propose de faire du multicast seulement avec une logique inverse à celle de SmartTools actuellement. LogNetPonDS ne publie pas les composants en entier, mais chaque services des composants et chaque service de sortie possède un tuyau de sortie identifié par le nom du composant + le nom du service de sortie. La connexion est inversée par rapport à la méthode habituel, car on connecte le composant qui requière un service de sortie et non le composant qui offre des services de sorties à un composant qui requière les services de sorties.

Nouvelle mécanique : Composant A -> Service de sortie B -> VirtPipeOuput? A-B -> Réseau -> VirtPipeInput? A-B -> Composant C -> Service entrée B Ancienne mécanique : Composant A -> Proxy de C -> VirtPipeOutput? C -> Réseau -> VirtPipeInput? C -> Composant C -> Service entrée B

Dans la nouvelle mécanique, A fait un seul envoi pour invoquer tous les composants connectés au service B. Alors que dans l'ancienne mécanique, A fait plein d'appels à tous les composants connectés au service B.

Par contre, comme je le disais, et à moins d'avoir 2 modèles de connexion, il est impossible de faire de l'unicast, car A n'a plus la connaissance du composant C. En effet c'est C qui réalise la connexion dans la nouvelle mécanique, alors que dans l'ancienne mécanique, c'est A qui réalise la connexion (avec le proxy de C).