Tulip utilise plusieurs types d’agents :

- Launcher : cet agent est lancé au démarrage de l’exécution et est indiqué par le fichier de configuration (balise <SCENARIO>). C’est le séquentiel racine qui lance les trafic (test) agents + (test) responder.

- Responder : agent utilisé pour traiter les paquets non reconnus par l’application (différents de ce qui est attendu par l’agent, ou non routable vers un agent).

- Test responder : agent utilisé pour traiter les paquets non reconnus par l’application en mode test (différents de ce qui est attendu par l’agent de test, ou non routable vers un agent de test).

- Trafic agent : agent créé par le launcher, qui exécute un fichier de commandes en parallèle. Chaque trafic agent est référencé dans le fichier de configuration (balise <AGENTS>), et possède des attributs spécifiques (TYPE et autre(s)paramètre(s) dépendant du mode choisi).

- Trafic test agent : agent similaire au Trafic agent, mais utilisé dans un contexte de test interne à tulip (simulation de l’environnement de test grâce à un rebouclage du pipeline de test). Il reçoit les paquets venant du trafic agent, et en envoie à destination des trafic agents.

- Commander : agent en mode interactif, recevant des séquentiels d’un pipeline et les exécutant. Typiquement il est utilisé dans le cadre du contrôle utilisateur de tulip, ou du contrôle à distance d’un tulip par une autre instance.

Tulip supporte de nombreuses configurations : le commander peut être présent ou pas, de même que le launcher, qui peut se terminer juste après avoir lancé les agents de trafic. Ci-dessous, les principales topologies utilisées :

1) Launcher only

Cette configuration correspond à un test fonctionnel, qui ne nécessite pas d’exécution en parallèle d’actions, ou de trafic. Dans ce cas, le launcher est exécuté, puis l’application se termine lors de la fin du launcher. Tout paquet reçu sera routé automatiquement vers le launcher, si celui-ci est en cours de réception.

2) Launcher + responder

Cette configuration correspond à un test fonctionnel, qui ne nécessite pas d’exécution en parallèle d’actions, ou de trafic. Dans ce cas, le launcher est exécuté, qui lance le responder : l’application ne se terminera que lorsque le launcher sera terminé. Tout paquet reçu sera routé automatiquement vers le launcher, si celui-ci est en cours de réception ; le cas échéant, ou si le packet n’est pas reconnu par le launcher, le responder sera sollicité.

3) OTHER only

Cette configuration est la plus basique pour le traffic. Les agents lancés sont activés selon la cadence décrite dans le fichier de configuration.

L’application s’exécute tant qu’il y a au moins un agent de trafic actif (ou le launcher).

Les paquets reçus sont routés vers le bon traffic agent, selon les critères de routage en vigueur dans le mode choisi (fichier de configuration, item <MODE>). Si aucun agent ne convient, le paquet est envoyé au launcher, ou en dernier recours au responder. Si le paquet est routé vers un traffic agent, mais ne correspond pas à ce qui est attendu, le paquet est routé vers le responder agent correspondant si possible.

4) Called only

Dans cette configuration, il est possible de simuler un serveur avec une architecture multi-processus (ex, un serveur web). Tous les traffic agents sont lancés simultanément, et exécutent leur commandes jusqu’à rencontre une commande d’attente de message. Le cadencement décrit dans le fichier d configuration n’est pas pris en compte.

L’application s’exécute tant qu’il y a au moins un agent de trafic actif (ou le launcher).

Deux cas de figures, en fonction du mode sélectionné dans le fichier de configuration (item <MODE>) :

- Si le mode correspond à un routage applicatif des paquets (tulip utilise la payload applicative pour router les paquets vers l’agent adéquat). Dans  ce cas, le traffic agent est activé et attend le paquet jusqu’à expiration du TAM (temporisation d’attente message). Le routage vers le responder des paquets non reconnus continue à être effectué.

- Si le mode correspond à un routage des paquets basé sur la couche transport (numéro de port pour UDP/TCP). Dans ce cas, le traffic agent reste inactif jusqu’à qu’il soit sélectionné par l’application (round robin).

5) Caller+Called

Dans cette configuration, il est possible de simuler un serveur multi-processus avec un rebouclage (ex, l’appel du CALLER est relayé vers le CALLED par le réseau téléphonique testé).

L’application s’exécute tant qu’il y a au moins un agent de trafic actif (ou le launcher).

Les traffic agents sont lancés par paire CALLER/CALLED, suivant le cadencement décrit dans le fichier de configuration. Deux cas de figure concernant le routage des paquets vers le CALLED:

- Si le mode correspond à un routage applicatif des paquets (tulip utilise la payload applicative pour router les paquets vers l’agent adéquat). Dans  ce cas, le CALLED agent qui reçoit le paquet est prédictible.

- Si le mode correspond à un routage des paquets basé sur la couche transport (numéro de port pour UDP/TCP). Dans ce cas, le CALLED traffic agent sera sélectionné par l’application (round robin).

Le responder peut également être utilisé dans cette configuration.

6) Any + Pool (local)

Dans cette configuration, un traffic agent de type POOL peut être sélectionné puis activé par un autre traffic agent. La sélection s’effectue en mode round robin, et un traffic agent ne peut contrôler qu’au plus un POOL agent. Cette topologie permet de lancer deux traitements en parallèle pour un même appel.

Lorsque le traffic agent maître se termine, l’agent pool est réinitialisé. L’application s’exécute tant qu’il y a au moins un agent de trafic actif (ou le launcher).

Le routage des paquets vers les agents POOL ou autre, s’effectue selon les critères établis pour le mode en cours, les agents POOL ne peuvent recevoir de paquets tant qu’ils ne sont pas actifs.

Voir la section Contrôle à distance pour plus de détails.

7) Any + Pool (remote)

Dans cette configuration, un traffic agent de type POOL peut être sélectionné puis activé par un traffic agent exécuté par une autre instance tulip. La sélection s’effectue en mode round robin, et un traffic agent ne peut contrôler qu’au plus un POOL agent. Cette topologie permet de lancer deux traitements en parallèle pour un même appel, et de distribuer l’exécution sur plusieurs machines.

Lorsque le traffic agent maître se termine, l’agent pool est réinitialisé. L’application s’exécute tant qu’il y a au moins un agent de trafic actif (ou le launcher).

Le routage des paquets vers les agents POOL ou autre, s’effectue selon les critères établis pour le mode en cours, les agents POOL ne peuvent recevoir de paquets tant qu’ils ne sont pas actifs.

Voir la section Contrôle à distance pour plus de details.

8) Launcher only (mode test)

Cette configuration permet de valider un scénario de test fonctionnel. Dans ce cas, le launcher est exécuté, et lance à son tour un agent de test. L’application se termine lors de la fin du launcher et de l’agent de test. Tout paquet reçu du réseau simulé sera routé automatiquement vers le launcher, si celui-ci est en cours de réception. Tout paquet envoyé vers le réseau virtuel sera routé vers le test agent si nécessaire.

9) Launcher + responder (mode test)

Cette configuration permet de valider un scénario de test fonctionnel. Dans ce cas, le launcher est exécuté, et lance à son tour un agent de test+responder. Si besoin, le test agent lance le test responder. L’application se termine lors de la fin du launcher et de l’agent de test. Tout paquet reçu du réseau simulé sera routé automatiquement vers le launcher si celui-ci est en cours de réception, ou alors le responder. Tout paquet envoyé vers le réseau virtuel sera routé vers le test agent si nécessaire, et le test responder le cas échéant.

10) OTHER only (mode test)

Cette configuration est la plus basique pour le traffic. Les agents lancés sont activés selon la cadence décrite dans le fichier de configuration.

L’application s’exécute tant qu’il y a au moins un agent de trafic actif (ou le launcher).

Les paquets reçus sont routés vers le bon traffic agent, selon les critères de routage en vigueur dans le mode choisi (fichier de configuration, item <MODE>). Si aucun agent ne convient, le paquet est envoyé au launcher, ou en dernier recours au responder. Si le paquet est routé vers un traffic agent, mais ne correspond pas à ce qui est attendu, le paquet est routé vers le responder agent correspondant si possible.

11) Called only (mode test)

Dans cette configuration, on peut valider un scénario de traffic multi-processus.

L’application s’exécute tant qu’il y a au moins un agent de trafic actif (ou le responder/launcher).

Tout paquet reçu du réseau simulé sera routé vers un CALLED agent, tandis que tout paquet envoyé vers le réseau virtuel sera routé vers un test agent si nécessaire.

Deux cas de figures pour le routage des paquets reçu du réseau simulé, en fonction du mode sélectionné dans le fichier de configuration (item <MODE>) :

- Si le mode correspond à un routage applicatif des paquets (tulip utilise la payload applicative pour router les paquets vers l’agent adéquat). Dans  ce cas, le traffic agent est activé et attend le paquet jusqu’à expiration du TAM (temporisation d’attente message). Le routage vers le responder des paquets non reconnus continue à être effectué. Le cadencement décrit dans le fichier de configuration est pris en compte pour lancer les agents CALLED.

- Si le mode correspond à un routage des paquets basé sur la couche transport (numéro de port pour UDP/TCP/SCTP). Tous les traffic agents CALLED sont lancés simultanément, et exécutent leur commandes jusqu’à rencontre une commande d’attente de message. Le traffic agent reste inactif jusqu’à qu’il soit sélectionné par l’application (round robin). Le cadencement d’appel décrit dans le fichier de configuration est seulement pris en compte pour les agents de test.

12) Caller+Called (mode test)

Dans cette configuration, on teste un scénario de traffic avec un rebouclage (ex, l’appel du CALLER est relayé vers le CALLED par le réseau téléphonique testé, soit l’agent de test MGC). Les traffic agents sont lancés par triplet CALLER/CALLED/MGC suivant le cadencement décrit dans le fichier de configuration.

Tout paquet reçu du réseau simulé sera routé vers un CALLER ou CALLED agent, tandis que tout paquet envoyé vers le réseau virtuel sera routé vers un test agent MGC si nécessaire.

Deux cas de figure concernant le routage des paquets vers le CALLED:

- Si le mode correspond à un routage applicatif des paquets (tulip utilise la payload applicative pour router les paquets vers l’agent adéquat). Dans  ce cas, le CALLED agent qui reçoit le paquet est prédictible.

- Si le mode correspond à un routage des paquets basé sur la couche transport (numéro de port pour UDP/TCP). Dans ce cas, le CALLED traffic agent sera sélectionné par l’application (round robin).

Les responder/test responder peuvent également être utilisés dans cette configuration.