Round-Trip Time (RTT), also called round-trip delay, is the time required for a signal pulse or packet in a network to travel from a specific source to a specific destination and back again. In our context, a RTTP may be composed of several rounds. In a single round, every node will send a message to each of its neighbors. This message will contain the initiator node, the responder node, and the time at which the message was sent (i.e., the request time). Once a responder receives a message, it retransmits it back to the initiator node. When the initiator node gets the response message, it computes the round-trip time by using its local clock, and stores the result together with the response message.
A network is made up of several nodes. Each node has an unique clock and can receive a few messages. To model the Rttp system structure we have specified the following metamodel:
Then, we describe a graphical concrete syntax for it by defining a gcs model. In a gcs model, we associate every class of the metamodel with a picture. The visual concrete syntax we have defined for the RTTP example is shown in the following figure.
We have used e-Motions to model the RTT measurement in a node's network. For this purpose we have designed four rules. Next figure shows the Request periodic rule.
Notice the link from the n2 node to the message in the RHS pattern, modeling that the message has arrived to its destination. This rule models the sending of a message m from a node n1 to one of its neighbors n2. This action takes between 5 and 20 time units. The message includes information about the initiator n1, the responder n2, and the time at which the message was originally sent (the requestTime). This latter value is computed by using the initTime variable, which gathers the value of the local clock at the triggering of the action. A different round of the RTTP will start every 100 time units.
This is a picture of the Response atomic rule:
When a node n2 receives a message m whose initiator is a different node n1, it retransmits the message back to the n1 node. The initiator will receive the message between 5 and 20 time units after, and will store it and compute its RTT by using the value of its local clock.
To model time elapse of local clocks, we have defined the LocalTimeElapse ongoing rule, which is shown in the following Figure:
Clocks increase their time value with the corresponding time elapse T. Note that we could have used the clock provided by the system instead for modeling this behavior. However, we have selected this option to show how easy an user can define his/her own (distributed) clocks.
Finally, the InitialModel rule generates a possible initial configuration for the system. This rule will be executed just once (the NAC pattern forbids the application of the rule if it was already realized before). The rule creates a network composed of two nodes n1 and n2, and their corresponding local clocks c1 and c2. In our case, we only consider n1 as an initiator node.
We can configure eMotions launcher to run the simulation as shown in the following figure:
We do not need to specify an initial model since we have a rule that creates it. Of course, we can simulate the system with different initial configurations by modifying the InitialRule. The result of the simulation can be analyzed by exploring both the received messages and its request times.
The RTTP-b.zip file contains the project with all files required to try this example: the metamodel definition, the graphical concrete syntax for the metamodel and its corresponding behavioral specifications. To import this project, right click on the navigation view Import...-> General -> Existing Projects into Workspace -> Select archive file and then select the RTTP-b.zip file.