L’application Tulip permet l’exécution de commandes décrites par un fichier séquentiel XML, suivant une configuration également au format XML (fichier de configuration).

Les commandes exécutées sont dynamiquement fournies sous la forme de plugins (librairies .dll dans le sous-répertoire lib de l’installation). Il y a deux types de plugins :

- General : commandes accessibles par n’importe quel séquentiel, comme par exemple les fonctions arithmétiques. Les plugins correspondants comportent le préfixe « tl ».

tlCommon.dll : fonctions logiques, mathématiques, d’accès au fichier.

tlCrypto.dll : fonctions de cryptologie.

tlSystem.dll : fonctions liées au système d’exploitation.

tlTime.dll : fonctions liées au temps.

tlUtils.dll : fonctions de contrôle tulip (test, contrôle à distance, gestion d’agent,..).

- Protocole : commandes liées au mode choisi dans le fichier de configuration. Tulip utilise le concept de surcharge objet : une commande déclarée dans une librairie Générale peut-être redéfinie dans une librairie protocole. Typiquement, les commandes d’envoi et réception de messages dans le protocole choisi figurent dans ces librairies.

Le nom d’une librairie protocole est dérivé du mode en question (ex, M2UA.dll).

L’automate tulip permet l’exécution séquentielle des commandes, ou/et parallèle (traffic).

Comme décrit dans le schéma, chaque séquentiel source XML est vérifié par rapport à la DTD (meta-description du fichier séquentiel), puis compilé dans un format .tlp. C’est ce fichier qui pourra être chargé/exécuté par le noyau de l’application.

Tulip comporte les principaux modules suivants :

- Compiler : prend en entrée l’ensemble un séquentiel XML à compiler, des fichiers DTD et le fichier de configuration. Il effectue ensuite des vérifications syntaxiques puis compile le fichier dans un format propriétaire. La sortie est un fichier .tlp directement utilisable. Il est à noter que la compilation peut être décorrélée de l’exécution proprement dite (faite une fois pour toute).

- Tulip CORE : noyau de l’application, qui initialise les différents éléments, interprète le fichier de configuration et charge les séquentiels compilés. Il contrôle également les agents décris ci-dessous.

- Agent : module s’exécutant sur un thread séparé, qui démarre par l’exécution d’un séquentiel XML racine (potentiellement d’autres par la suite), et dispose de son propre espace de variables. A noter que chaque exécution subséquente d’autres séquentiels par ce même agent utilisera un nouvel espace de variables locales.

- Internal router : module spécifique à chaque mode, permettant le routage d’un paquet reçu du pipeline testé (ex, un socket UDP) vers le bon agent, ou le répondeur si présent.

- Scheduler : lorsque tulip est utilisé pour faire du trafic, ce module active un agent tutes les périodes d’intersimulation afin d’obtenir le débit cible (ex, CAPS).