Bonjour,
Mes remarques directes sont incluses dans votre mail initial.
ainsi que des remarques plus générale sur TSP, CORBA et OMG-DDS à la
fin du mail.
Le 03/02/06, PEREMANS, Yves <address@hidden> a écrit :
Ce logiciel dispose d'un composant 'middleware' qui assure la
distribution des données
à la fois brutes ( des trames de bits non traitées) et décodées.
A priori TSP est plutôt un service d'observation de données qu'un
middleware orienté
vers l'échange multi-partie de données.
Dans l'état actuel du code TSP ne transporte que des flottants double
precision,
mais la gestion de types simples (entier signés ou non de 8 à 64bits
et flot d'octet et autres
string) et tableaux sont planifiés pour fin mars début avril 2006, pour
un autre
utilisateur TSP, à savoir le CNES.
Ce composant implémente un protocole publish/subscribe et est
actuellement
implémenté avec CORBA TAO.
Serait-ce possible d'avoir des précisions?
Quel(s) services CORBA sont utilisés pour mettre en oeuvre votre MDW:
1) IMR
2) NamingService
3) NotificationService
4) OMG DDS (http://www.omg.org/docs/formal/04-12-02.pdf)
Je vous demande ça car celà pourrait donner des indications quant à la
complexité
actuelle de l'implémentation du service et des performances associées,
indépendamment de l'API.
Un stagiaire pourrait travailler sur la modification de
l'implémentation de ce composant, passant
ainsi de TAO à TSP. l'intérêt de cette activité serait d'améliorer
les performances intrinsèques du
composant (les performances actuelles sont acceptables, mais de
meilleures performances
permettraient de répondre à de nouveaux besoins).
TAO n'est utilisé que pour MDW?
A supposer que TSP remplace TAO pour "l'implémentation" de MDW je suppose
que MDW lui-même devra garder son API CORBA pour ne pas avoir d'impact
sur les autres composant d'OC qui l'utilisent?
- qu'il n'y a pas, dès le départ, un point technique qui serait
rédhibitoire.
Afin de vous aider à me répondre,
A mon avis (mais ça n'engage que moi :)),
il pourrait y avoir certains points rédhibitoires, notamment la
richesse de votre
API publish/subscribe qui peut fonctionner sur un mode évènementiel
ce qui n'est pas le cas de TSP (voir ci-après).
Distributing the parameters
MDW offers the general publish/subscribe service which allows
applications to publish
parameters and to subscribe to some parameters. In the following, an
application publishing
parameters is called indifferently a Producer, a Publisher or a
Supplier. In the same way, an
application which subscribes to parameters is called a Consumer or a
Subscriber.
TSP est plutôt client/serveur que 3tiers ou "middleware" dans le sens
ou un consumer
peut consommer des sources de données de +ieurs provider mais TSP
n'avait pas pour
objectif d'être un moyen d'échange bi-directionnel de données.
On peut évidemment écrire des programmes qui sont à la fois producteur
et consommateur
mais ce n'est pas le cas des applications TSP actuels.
Le schémas classique d'utilisation de TSP aujourd'hui est
l'observation ou le stockage
à grande vitesse/débit de données "observée" dans un ou +ieurs "provider
TSP".
Un provider TSP peut bien sûr accepter des connexions de clients
multiples ce qui
donne des configurations multi-consumer <-->multi-provider mais avec 1
lien
(1 socket) par connection consumer <--> provider.
Provider TSP = Producer / Publisher / Supplier
Consumer TSP = Consumer / Subscriber
A Subscriber
may subscribe parameters on dynamic attribute value (DAV) change or
on new occurrence. A
Subscriber may also subscribe parameters which are in alarm status.
Une autre différence majeure entre TSP et MDW est qu'aujourd'hui TSP est
"essentiellement" synchrone.
C'est-à-dire que lorsqu'un provider décide de pousser un jeu
d'échantillons
TSP les consumers qui s'y sont abonnés recevront TOUTES les valeurs
auxquelles
ils se sont abonnées et ce même si elle n'ont pas changés. Le
consommateur
TSP DOIT consommer (dépiler d'un RINGBUF interne à la partie consumer)
TOUS les échantillons qu'il a demandé. Si il ne consomme pas assez vite
alors le provider empilera un symbole spécial "PERTE DE SYMBOLE"
et la connection avec ce consumer sera abandonnée par le provider.
Dans l'état actuel du code il n'y a donc pas d'abonnement (subscribe)
"sur changement de valeur", il y a dans les spécifications TSP (et dans
le code
actuel) des extensions prévues dans ce sens (GROUPE ASYNCHRONE).
L'objectif était clair, dans un cadre temps réel si les échanges TSP
"fonctionnent" pendant 1 cycle [de simulation] alors ils fonctionneront
encore jusqu'à la fin de la simulation, car le travail à effectuer ne
changera pas
(tant qu'on ne rajoute pas des consumers ou des providers dynamiquement).
A partir de TSP 0.7.0 un consumer TSP peut aller consulter de façon
asynchrone
la valeur d'un symbole (=couple nom/valeur) sans demander d'échantillon
SYNCHRONE.
MDW allows to distribute other kinds of values :
OCDS and BDUPD values, which are described in their respective ICD.
For those well known values, heavy flows may be assumed by the MDW.
Comme je le disais plus haut TSP ne gère aujourd'hui que les "double"
à venir les autres types ainsi que les tableaux d'ici fin mars 2006.
MDW proposes a function which allows to get the last known DAV of a
given parameter.
This function must be very efficient. THat's why all the current
values of the DAV
are available in a shared memory.
Il existe dans les librairies utilitaire un composant "Blackboard" qui
permet
de construire des providers très rapidement, en gros en 1heure et un
peu de courage
on transforme une application "normale" en un provider TSP.
C'est une mémoire partagée structurée qui implémente une API
publish/subscribe basique mais efficace en mémoire partagées (IPC
Système V).
On pourrait également utiliser un blackboard côté client/consumer.
Le blackboard, au contraire de TSP peut héberger n'importe quel type
de données y compris des types utilisateurs.
Il existe un provider TSP 'tout' prêt capable de se connecter à un
blackboard
et de distribuer les variables reconnues (y compris les types simple
qui sont convertis en double par le bb_tsp_provider).
Le Blackboard TSP est également
utilisé pour la communication inter-modules d'une même application
(simulateur par exemple).
MDW proposes a service which allows a client to get the next DAV of a
given parameter. This service may be blocking or not blocking ( or in
other words, synchronous or asynchronous). This service may return
error codes, for example on expiration of a given time-out.
Pour TSP synchrone = garantie de prélèvement temporelle côté provider
asynchrone = consultation de valeur sans garantie de
temps
l'API consumer synchrone permet de consulter si des échantillons sont
présents dans le ring buffer, si on lit un ring buf vide on ne bloquera
pas
mais on ne lira pas de valeur.
pour l'API asynchrone c'est un appel RPC dont le timeout est celui
qu'on a configuré lors de la construction de la lib TSP pour TOUS
les appels RPC.
MDW is able to perform a hot start. This means that this component is
able to get back all the needed information's on the current producers
and parameters published at initialization from a master MDW component
located on another host.
Il n'y pas de fonctionnalité de "redondance" entre provider dans TSP.
Un provider peut toutefois s'abonner facilement à tous les symboles
d'un autre provider et les redistribuer.
la structure corba utilisée pour les échanges producer => server =>
subscriber
<<OCMDW_dav.idl>>
Je dirais qu'ici est la différence la plus notable entre TSP et un
échange
d'objet ou de structure CORBA 'auto référencée' (qui est auto-descriptif
d'après ma compréhension). est le volume de donnée échangée.
Si je suppose que la structure ParamSampleStruct fait environ 40 octets.
le parametre de timestamp 'mandatory' contenant 2 ccTime 16 octets
Pour chaque valeur échangée entre un publisher et un subscriber
transiteront environ 56 par symbole.
Avec TSP, une fois que consumer et provider se sont mis d'accord
il y aura exactement 8 octets d'échangés (la taille d'un double)
+ 4 octets pour l'ensemble de toutes les valeurs.
En gros un consumer s'abonnant à 500 variables produites à100Hz
consommera:
(500*8 + 4) *100 = 400,4 Kbytes/s pour TSP
et
(500*56)*100 = 2,8 Mbytes/s pour MDW
La comparaison n'est pas juste car je postule le cas
pire ou toutes les valeurs changent à chaque cycles.
En gros TSP a été conçu pour répondre à un besoin de performance
maximum au détriment d'un certains nombre de fonctionnalités.
D'avance , je vous remercie pour l'attention que vous prterez à ma
requête.
En résumé je dirais qu'utiliser TSP à la place de TAO semble
envisageable mais il faudra coder "ce qui manque au niveau"
asynchronisme/évènementiel et c'est probablement un travail important
mais
néanmoins intéressant.
Personnellement je pense que dans un contexte TAO/CORBA
j'étudierais conjointement l'option DDS
http://www.omg.org/docs/formal/04-12-02.pdf
dont il existe désormais une implémentation open-source pour TAO:
http://www.ociweb.com/products/dds
ou même java
http://www-adele.imag.fr/~donsez/dev/dds/readme.html
Pour les aspects "purements" techniques
1) le lien de commande TSP
actuel est ONC-RPC mais l'API provider permet de plugguer
d'autres sorte de 'request_handler' un prototype de handler
XML_RPC a été testé, on pourrait assez facilement implémenter
un request handler CORBA/TAO.
2) L'encodage des données est XDR et pas CDR mais il existe
pléthore de librairies pour gérer l'XDR.
3) TSP n'a pas été porté sur la plate-forme windows pour la partie
écrite en C.
C'est faisable (appel POSIX, IPC SysV et pthread) mais celà
n'a pas été fait car personne n'en a eu besoin pour l'instant.
(Il existe toutefois une lib 100% Java pour la partie consumer) TSP
Merci d'avoir réussi à lire ce mail jusqu'au bout :)))
--
Erk
_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel