Once a data flow server is started on a machine, client nodes can be launched. There are two ways to start client nodes and connect them together through flows. The Control Center provides a graphical way to connect clients together. It is however possible to launch client nodes from the command line. When a client node is launched, it connects to its local server and usually creates flows. The NDFS-II then establishes the connections between client nodes through flows based on the information hard coded in the flow declaration.
Flows’ connections are hard coded. So connection between client nodes can be established just by launching the client nodes. This behavior is very convenient but can be too restrictive. We provide a way to override the flow connection IDs and therefore change the connection between clients during flow creation.
For example, the producer client node creates an output flow as follows:
flowOut = makeOutputFlow(“Flow_Audio_Array”, “myFlowOut”, “”, “Audio1”);
and let's say consumer1 creates an input flow:
flowIn = makeInputFlow(“Flow_Audio_Array”, “myFlowIn”, “”, “Audio1”);
The input and output flows of both client nodes have the same flow type, Flow_Audio_Array, and the same connection ID, Audio1. So when both clients are launched, the system connects these clients together through the flow.
Let’s take consumer2, which creates an input flow:
flowIn = makeInputFlow(“Flow_Audio_Array”, “myFlowIn”, “”, “Audio2”);
Here, the flow type Flow_Audio_Array matches with the producer flow type. The connection ID Audio2 from consumer2 however does not match the connection ID Audio1 of the producer. So when consumer2 is launched, it won’t be connected to the producer. It is however possible to override the connection ID when starting a client node by providing an argument on the command line, by launching consumer2 as follows:
consumer2 --sf flow-myFlowIn=Audio1
The connection ID Audio2 of the flow named myFlowIn is overridden by the connection ID Audio1 provided as an argument in the command line. Consumer2 is now able to consume the data produced by the provider.
So to override the ID of a flow when launched from the command line, the option --sf flow- should be immediately followed by the name of the flow specified in the code, then the ‘=’ sign, and finally the new assigned connection ID:
consumer_executable --sf flow-flow_name=newID
In an NDFS-II application, client nodes must have a unique name. It is however possible to use at the same time several instances of a client node as long as they have different names. The name used is the name provided in the Smartflow::connect_to_application_server() method. If not specified, the name of the executable (argv) will be used. If several instances of the same client node are launched without any parameter at the same time, only the first one connecting to the local data flow server will be accepted. The remaining ones will be denied access because they have the exact same name.
In order to start several instances of the same client node from the command line, each one of them needs to register to the server with a different name. One of them can keep its original name, while the other ones have to register with a new name. It is possible to override a client name using parameters of the command line. For example, when consumer1 is started like this:
consumer1 --sf clientname=new_client_name
The client node registers itself as new_client_name to the data flow server. It is useless to override the parameter yourself when using the Control Center because it does it automatically if necessary.
Some additional parameters can be given when launching any client nodes. These parameters are used by the Control Center but users could take advantage of them depending on their needs.
It is possible to specify the path of the executable file of the client node. This information is used by the Control Center. The Control Center is able to discover and take control of an application. After discovering the running application on the NDFS-II network, it can stop the client nodes running. But it often cannot restart them because it cannot know where the client node executable file is located. In order to specify this path, launch a client node like this:
consumer1 --sf clientpath=/path/of/the/executable/consumer1
This parameter is automatically used by the Control Center when one starts a client node. If you want to be able to start a client node from the command line, discover it using the Control Center, stop it from the Control Center and restart it from there, you need to specify the location of the client node executable when launching it.
The Control Center is able to make connection between client nodes through flows. It can request a description of the running application from the data flow server. Any client node and its active flows will be displayed. A client node may also provide or consume flows, which have not been created yet but will be later. In that case, the inactive flows won't be displayed because they are not registered with the data flow server yet. There is a way to launch a client node from the command line and specify flows that the client node will use. If a client node uses that option, the Control Center will be able to display a representation of every flows of the client node even if some flows have not been created yet. This parameter has originally been introduced for the Control Center.
The parameter --sf flowinfo automatically parsed by the Control Center gives a string representing flows described by their direction, flow name and flow type. Following is an example showing how to use it:
myClient --sf flowinfo=I%myFlowIn%Flow_Audio_Array%%O%myFlowOut%Flow_Audio_Array
The string describes every flows that the client node can eventually create. It should be in sync with the flows, that may be created in the source code of the client node. The flow list is represented by a string. The % character is used as a delimiter to identify the flow direction, flow name and flow type within the string. The %% delimiter is used to separate flow's description within the string. It is used as this:
The direction can be either:
I for an input flow
O for an output flow
The flow_name is the name of the flow as specified in the code as the second parameter of the makeInputFlow() or makeOutputFlow() method.
The flow_type is the type of the flow as specified in the code as the first parameter of the makeInputFlow() or makeOutputFlow() method.
Created on 2008-06-18 by Antoine Fillinger - Last updated on 2008-11-23 by Antoine Fillinger