 |
|
Tulip uses several kinds of agents:
- Launcher: this agent is started at the beginning of the application, and is defined in the configuration file (<SCENARIO> anchor). This agent then starts the trafic agents and responder.
- Responder: agent used to process unrecognized packets received from input pipeline (different from what an agent expects, or which cannot be routed to a test agent).
- Test responder: agent used to process unrecognized packets received from input pipeline in mode test (different from what an agent expects, or which cannot be routed to a test agent).
- Traffic agent: started by launcher agent, which executes a scenario in parallel (on a separate thread). Each traffic agent is referenced in the configuration file (<AGENT_xxx> anchor), and has its own specific attributes (TYPE and other parameters depending of the chosen mode).
- Traffic test agent: started by launcher agent, which executes a scenario in parallel (on a separate thread). Each test traffic agent is referenced in the configuration file (<AGENT_TEST> anchor), and has its own specific attributes (TYPE and other parameters depending of the chosen mode). The test traffic agents receive packets from the test input pipeline.
- Commander: interactive mode agent, which executes scenarii provided by standard input. Typically, it is used to enable user control of Tulip, or remote control by another Tulip instance.
Tulip supports multiple configurations: the commander can be started or not, as well as the launcher, which may stops right after starting the traffic agents. Below, the main topologies used:
1) Launcher only
This configuration corresponds to a functional test, which does not require parallel execution, or traffic. In this case, the launcher is executed, then the application will end only when the launcher agent is finished. Every packet received will be automatically routed towards the launcher, if it is receiving packets (EXPECTED command).
2) Launcher + responder
This configuration corresponds to a functional test, which does not require parallel execution, or traffic. In this case, the launcher is executed, which starts the responder: the application will end only when the launcher agent is finished. Every packet received will be automatically routed towards the launcher, if it is receiving packets (EXPECTED command); if not, or if the packet does not correspond to what the launcher is expecting, the packet will go to the responder agent.
3) OTHER only
This is the most basic traffic configuration. The traffic agents started by the launcher are activated according to the rate described in the configuration file. The application is running as long as there is at least one traffic agent or the launcher process that is not finished. The packet received are routed towards the correct traffic agent based on routing criteria and traffic agent attributes (this depends on the chosen mode in configuration file). If the packet cannot be routed, it goes to the launcher, if it is running and receiving, otherwise it goes to the responder. If the packet is correctly routed to a traffic agent, but does not match the expected pattern, or if the traffic agent is not receiving, the packet goes to the traffic agent dedicated responder if possible.
4) Called only
In this configuration, it is possible to simulate a server with multithreads architecture (ex, web server). All traffic agents are simultaneously launched, and execute their scenarii until a message is expected (then it goes to standby). The period rate mentioned in the configuration file is not taken into account here. The application is running as long as there is at least one traffic agent or the launcher process that is not finished.
Two cases, depending on the selected mode in the configuration file (<MODE> item): - If the mode contains applicative routing of the incoming packets (means Tulip will inspect the applicative payload in order to select the correct traffic agent). In this case, the traffic agent is activated from the beginning and wait for a packet until the TAM expires (message reception timeout). The routing of unknown messages to the responder is still performed. Consequently, it is important to dimension correctly the first TAM, so that it will not expire before the last agent is selected. - If the mode corresponds to a transport-level routing of the packets (port number for UDP/TCP). In this case, the traffic agent will remain inactive until it is selected by the application (round robin).
5) Caller+Called
In this configuration, it is possible to simulate a multithread server with a loop (ex, an incoming call from a caller party is relayed to the called party by the tested phone network). The application is running as long as there is at least one traffic agent or the launcher process that is not finished. The traffic agents are activated two by two, based on the type (CALLER+CALLED), following the sequencing in the configuration file (nth CALLER paired with nth CALLED). Two cases when routing incoming packets towards CALLED agent: - If the mode contains applicative routing of the incoming packets (means Tulip will inspect the applicative payload in order to select the correct traffic agent). In this case, the called traffic agent is determined based on its attribute (ex, SIP URI). - If the mode corresponds to a transport-level routing of the packets (port number for UDP/TCP). In this case, the traffic agent is selected by the application using round robin algorithm. A responder can also be used in this configuration.
6) Any + Pool (local)
In this configuration, a traffic agent which has the TYPE set as “POOL” can be selected then activated by another traffic agent. The selection is performed following round-robin algorithm, and a traffic agent may control at most one POOL traffic agent. This topology allows launching two processing in parallel for a same period (ex, signaling + data). As soon as the master traffic agent stops, the pool agent is resetted and may be selected by another agent. The application is running as long as there is at least one traffic agent or the launcher process that is not finished. The routing of incoming packets towards the pool agent follows the rules defined for the chosen mode (applicative level routing, or transport level). Pool agents may not receive packets until they are activated. See remote control section for more details.
7) Any + Pool (remote)
In this configuration, a traffic agent with type POOL may be selected then activated by a traffic agent from another Tulip instance. The selection is performed as a round robin, and a traffic agent may control at most one other agent. This topology allows to perform to treatments in parallel for a same period, and to distribute the execution load across several machines. As soon as the master traffic agent finishes, the slave pool agent is resetted. The application is running as long as there is at least one traffic agent or the launcher process that is not finished. The routing of incoming packets towards the pool agent follows the rules defined for the chosen mode (applicative level routing, or transport level). Pool agents may not receive packets until they are activated. See remote control section for more details.
8) Launcher only (mode test)
This topology can be used to validate a functional scenario, and uses test pipeline loop. As soon as launcher starts it executes a test traffic agent. The application ends as soon as launcher and test traffic agent are finished. Every packet received from test pipeline is routed towards the launcher if it is receiving. Every packet sent by the launcher will be routed towards test traffic agent if possible.
9) Launcher + responder (test mode)
This configuration allows validating a functional test scenario. In this case, the launcher is executed, than it starts a test agent and responder. If needed, the test agent starts also a test responder. The application will end when the launcher + test agents are both finished. Every packet received from simulated test input pipeline will be routed to the launcher if it is running and expecting a packet or the responder otherwise.
10) OTHER only (test mode)
This configuration is the most basic for traffic purpose. The traffic agents are activated at the pace described in configuration file. The application is running as long as there is at least one traffic agent or the launcher process that is not finished. Every packet received from simulated test input pipeline will be routed to a traffic agent according to the relevant routing criteria, or the responder in last resort. If a traffic agent cannot match an incoming packet, the packet is transmitted to the corresponding responder agent if possible.
11) Called only (test mode)
This topology allows testing a multi-process traffic scenario.
The application is running as long as there is at least one traffic agent or the launcher process that is not finished. Every packet received from simulated test input pipeline will be routed to a CALLED traffic agent, while all packets sent to that pipeline will be routed towards a test agent (or test responder if applicable). There are two cases regarding incoming packet routing to the correct CALLED traffic agent, depending of the selected mode in configuration file (<MODE> anchor):
- If the mode corresponds to an application level routing (Tulip uses the applicative apply to decide where to route the packet towards the correct traffic agent). In this case, the traffic agent is activated normally (cf CALLER+CALLED scenario), and will wait for messages until expiration of timer TAM. Unrecognized packets will still be routed to responder agent. The call rate specified in the configuration file is used for the CALLED traffic agents activation.
- If the mode corresponds to a transport level routing (using UDP/TCP/SCTP port number). All CALLED agents are launched simultaneously, and execute commands until reaching the first packet reception command: each traffic agent then stays inactive until selected by the application (round robin algorithm). The call rate specified in the configuration file is only used for the test agents activation.
12) Caller+Called (test mode)
In this configuration, it is possible to test a traffic scenario (ex, the call from CALLER agent is routed back towards CALLED subscriber by tested phone network, or test traffic agent. Every packet received from the simulated test input pipeline will be routed to a CALLER or CALLED traffic agent while the packets sent to the pipeline will be routed to a test traffic agent (MGC type). It is possible to used responder and test responder, which provide a last resort routing.
Two cases regarding CALLED party packet routing.
- If the mode corresponds to an application level routing (Tulip uses the applicative apply to decide where to route the packet towards the correct traffic agent). In this case, the traffic agent is activated normally (cf CALLER+CALLED scenario), and will wait for messages until expiration of timer TAM. Unrecognized packets will still be routed to responder agent. The traffic agents are launched in groups of three CALLER/CALLED/MGC according to the call rate defined in configuration file.
- If the mode corresponds to a transport level routing (using UDP/TCP/SCTP port number). All CALLED agents are launched simultaneously, and execute commands until reaching the first packet reception command: each traffic agent then stays inactive until selected by the application (round robin algorithm). The call rate specified in the configuration file is only used for the CALLER/MGC traffic agents activation.
|
| Topologies |
|
 |
