Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Eclipse Titan product structure part 2(protocol daemon, dynamic daemon, dynamic vs. static, persistent vs. transient, TRI, transport layer, SCTP)
Eclipse Titan product structure part 2 [message #1823699] Tue, 31 March 2020 10:24
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Dear all,



let's revisit briefly the use cases exposed in the SCTP post series. They typically consist
of a TTCN-3 test suite connected to the OS stack with an SCTP (be that SCTPasp or IPL4asp)
test port appropriately configured:

  +--------------------------------+                  +--------------------+
  |                                |                  |                    |
  |                                |                  |                    |
  |                                |                  |                    |
  |       TTCN-3 test suite        |                  |                    |
  |       (transient)              |                  |                    |
  |                                |                  |                    |
  |                                |                  |                    |
  |                                |                  |                    |
  +----------------+---------------+                  |                    |
transport layer    |                                  |    SUT             |
      test port    |    kernel stack                  |                    |
  +----------------v---------------+                  |                    |
  |                                |                  |                    |
  |          transport layer(SCTP) |                  |                    |
  +--------------------------------+                  |                    |
  |                                |                  |                    |
  |             IP                 |                  |                    |
  +--------------------------------+                  |                    |
  |                                |                  |                    |
  |             .....              |                  +-----------^--------+
  +----------------^---------------+                              |
                   |                                              |
                   |                                              |
                   |                                              |
                   +----------------------------------------------+



All code will compile into a monolithic executable; when execution is started, the user layer protocol,
described by the test suite, will bind to an SCTP socket, some messaging takes place,
then, as execution is finished, the MTC component is destroyed and the user layer unbounds, the service connected
to the transport layer disappears. And here's the problem: this leads to an unrealistic simulation, as
in the real life, services bound to a transport layer will not suddenly vanish, but tend to persist.
What's more, sudden apparition of services at the start of execution may cause unwanted transients while changes propagate
through the network, services popping up are acknowledged and taken into account by other nodes in the network etc.
Similarly, disappearing services may cause supervisions and monitoring in these nodes to trigger alarms and so on.
Hence, it would be desired that services bound to the transport layer appear as persistent; but this conflicts with the fact
that at the termination of execution the TTCN-3 test suite dies. (BTW, our example is of an SCTP use case, but the logic is valid
for all kinds of transport layers).
This leads to the separation of the code into a persistent part (named SCTP daemon in the figure below)
and a transient part, the TTCN-3 test suite itself. Those familar with all chapters of the TTCN-3 standard will immediately
spot the fact that this separation is along the lines of the standardized TTCN-3 test suite and the implementation dependent
TRI (Runtime interface) as described in the standard, architecture not explicitly (but implicitly, as can be seen) supported by Titan.

+-----------------------------+          +--------------------------------+                  +--------------------+
|                             |          |                                |                  |                    |
|                             |          |                                |                  |                    |
|                             |  TCP     |                                |                  |                    |
|      TTCN+3 test suite      |          |       SCTP daemon (persistent) |                  |                    |
|      (transient)            <---------->                                |                  |                    |
|                             |          |                                |                  |                    |
|                             |          |                                |                  |                    |
|                             |          |                                |                  |                    |
+-----------------------------+          +----------------+---------------+                  |                    |
                                  transport layer (SCTP)  |                                  |    SUT             |
                                        test port         |    kernel stack                  |                    |
                                         +----------------v---------------+                  |                    |
                                         |                                |                  |                    |
                                         |      transport layer (SCTP)    |                  |                    |
                                         +--------------------------------+                  |                    |
                                         |                                |                  |                    |
                                         |             IP                 |                  |                    |
                                         +--------------------------------+                  |                    |
                                         |                                |                  |                    |
                                         |             .....              |                  +-----------^--------+
                                         +----------------^---------------+                              |
                                                          |                                              |
                                                          |                                              |
                                                          |                                              |
                                                          +----------------------------------------------+


Thus far, three such persistent components called daemons have been published in the Eclipse Titan ecosystem,
see https://github.com/eclipse/titan.core , "Servers":

http://git.eclipse.org/c/titan/titan.Servers.GTP_Tunnel_Daemon
http://git.eclipse.org/c/titan/titan.Servers.IP_Daemon_Dynamic
http://git.eclipse.org/c/titan/titan.Servers.SCTP_Daemon_Dynamic

They are typically compiled in single mode, and started separately, before starting the test suite itself.
The test suite when started will connect to the daemon and commence messaging which will be relayed by the daemon to the SUT.
At the end of execution, the test suite terminates but the daemon will persist, rendering the simulation more life-like, while
the test suite can be re-executed as many times as needed.
Daemons can be static (that is, completely set by parameters in the configuration file) or dynamic (that is, run-time configurable
via messages from the user layer), same logic as applied in the case of many test ports.



In the next part, a concrete usage example of the SCTP daemon will be presented.


Best regards
Elemer
Previous Topic:Eclipse Titan product structure part 1
Next Topic:Eclipse Titan product structure part 3
Goto Forum:
  


Current Time: Sun Dec 22 06:22:26 GMT 2024

Powered by FUDForum. Page generated in 0.03097 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top