Main Page/Resources/E-motions/RTTPexample

From Atenea

Jump to: navigation, search

Contents

Introduction

Round-trip time (RTT), also called round-trip delay, is the time required for a signal pulse or packet to travel from a specific source to a specific destination and back again. In this context, the source is the computer initiating the signal and the destination is a remote computer or system that receives the signal and retransmits it.

In a network, particularly a WAN (wide-area network) or the Internet, RTT is one of several factors affecting latency, which is the time between a request for data and the complete return or display of that data. The RTT can range from a few milliseconds (thousandths of a second) under ideal conditions between closely spaced points to several seconds under adverse conditions between points separated by a large distance. In the context of computer networks this time is also known as ping time.


Image:rttp3.png

System Modeling

Structure

In this example we model a network of interconnected nodes that exchanges messages between them. A network has nodes and messages. Nodes have a clock to measure the RTT parameter. There are several kinds of messages, it depends on whether the message is incoming, outgoing, open or closed. For this purpose we have designed the following metamodel:


Image:RttpMM.png


We associate every class of the metamodel with a picture. This graphical concrete syntax will be used for the definition of the behavioral rules.


Image:RttpGCS.png



Behavior

We have designed several rules to model the behavior of a node's network in order to measure the RTT parameter.


Image:RttpaRules.png


The InitialRule creates the initial model. This model consists of a network composed of five nodes and three clocks. The NAC pattern forbids the triggering of the rule if was already performed before.


Image:InitialRttpa.png


The NewMessage rule models the sending of a message m from a node to one of its neighbors. If two nodes are connected and none of them is sending or receiving messages, a new message will be generated. The exact moment in time in which the message is sent will be stored in the time attribute of the message.


Image:NewMessage.png


The MessageArrives rule specifies the shipment of a message to its destination. It takes between 2 and 8 time units. Note the message in the RHS pattern is not like the message in the LHS pattern. The first one is a SealedGoMessage class element, in other words it is a sent message. The second one is a GoMessage class element, which means that it is an arrived message.


Image:MessageArrives.png


Once a message is delivered to its destination node, such node will send a reply message to the source node.It is specified by the NeighborGetsMessage rule. We use a SealedBackMessage class element to specify the reply message. Note the link from the message to the id1 node in the RHS pattern is not like the one in the LHS pattern. id1 node performs the target role in the RHS pattern. On the contrary, it is the source node in the LHS pattern. The same happens with the link from the message to the id2 node.


Image:NeighborGetsMessage.png


The RecycledMessageArrives rule performs the same behavior as the MessageArrives rule. The only difference among them is that the first one specifies the shipment of a reply message.


Image:RecycledMessageArrives.png


The RoundTripCompleted rule is shown in the following figure. The initiator will receive the message between 2 and 8 time units after it was sent by the responder node. Then the initiator node will store it and compute its RTT by using the value of its local clock, with the exception of the rule cannot be applied if the RTT parameter is higher than 20 time units. In such case the DiscardLateMessage rule will be triggered and the message will be discarded.


Image:RoundTripCompleted.png Image:DiscardLateMessage.png


Finally, to model time elapse of local clocks, we have defined the LocalTimeElapse ongoing rule, which is shown in the following figure:


Image:LocalTimeElapse.png

Simulation

We can configure eMotions launcher to run the simulation as shown in Figure:


Image:LauncherRttpa.png


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 the rtt attribute of each node.


Image:OutRttpa.png


Download

The RTTP-a.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-a.zip file.

Personal tools