It is possible to control one or more remote tulip instance from a master tulip instance. To do so, it is necessary to perform some commander declarations in the configuration file.

Element <COMMANDER>, which instantiates a commander. It can be of three types, as positioned by the “MODE” attribute.

                     LOCAL: commander which takes as input the application standard input (e.g. the keyboard). This mode allows interactive control of a tulip instance. In this case, the attribute “NAME” is only used to identify the current instance.

                     REMOTE: master network commander, located usually on another machine. In this case, the tulip instance is controlled by another one, instantiated this way. The remote FQDN, or IPV4 address is contained within the “HOST” attribute. “PORT” attribute contains the local TCP port. The “NAME” attribute is not used. The attributes LOG+STATS permit to specify whether log/statistics flows should be redirected or not towards remote instance (otherwise they go through standard output).

                     SERVER: slave network commander, located usually on another machine. The HOST/PORT fields identify the network address/port of the commander. The “NAME” attribute identifies the network commander. The LOG/STATS attributes are not used.

Master side:

<COMMANDER MODE="SERVER" NAME="xxx" HOST="xxx » PORT="xxx"/>

It is also possible to declare a local commander :

<COMMANDER/>

Slave side:

<COMMANDER MODE="REMOTE" HOST="xxx" PORT="xxx" LOGS="LOCAL" STATS="LOCAL"/>

The remote control can be used in two ways :

1)      Scenario remote execution

The <RSEQ> command allows the execution of a scenario by a slave Tulip instance. The scenario is executed by the commander of the remote instance.

Example:

<RSEQ COMMANDER=”COMMANDER1” VAR_OUTPUT=”VAR”>

<PRINT>Executed from remote</PRINT>

</RSEQ>

Here, a variable is specified so that the output of the scenario will be put into that variable “VAR”.

2)      Execution of a distant agent of type «POOL»

TULIP proposes some primitives to select/control a distant agent chosen among a pool. A master agent can be assigned at most a single pool agent. A POOL agent is declared as such in the configuration file with the TYPE attribute set to “POOL”. One started, it starts waiting for a selection.

It is possible for a master agent to use the following primitives:

            <SELECT_POOL_AGENT>: pool agent selection. It is possible to specify the network commander on which to perform the selection (“COMMANDER” attribute). The pool agent stays inactive, but is now assigned to a master agent as long as it is executing and POOL agent is not finished.

<ACTIVATE_POOL_AGENT>: activation of a previously selected pool agent and not already activated. The pool agent then starts its execution. At the end of the execution, the pool agent is released.

<RESET_POOL_AGENT>: release of a pool agent already activated. The pool agent execution is stopped and the agent is restarted and may be selected again. The master agent can select another pool agent.

<WAIT_POOL_AGENT>: blocking command until the selected and activated pool agent is finished. The master agent can then select another pool agent.

<GET_PARAM_POOL_AGENT>: this primitive allows interrogating a pool agent. It gets the current value of a traffic parameter within pool agent scope and places it into the specified variable.

<SET_PARAM_POOL_AGENT>: position a traffic parameter on the selected pool agent (no need to be activated). If the parameter does not exist already, it is created.

<GET_PORT_POOL_AGENT>: this primitive interrogates the selected pool agent transport layer port. It stores the value within the provided variable.