doc/SCTP Daemon Dynamic for TTCN-3 Toolset with TITAN User Guide.adoc

---
Author: Tímea Moder
Version: 198 17-CNL 113 630, Rev. A
Date: 2012-05-14
---
= SCTP Daemon Dynamic for TTCN-3 Toolset with TITAN, User Guide
:author: Tímea Moder
:revnumber: 198 17-CNL 113 630, Rev. A
:revdate: 2012-05-14
:toc:

= Introduction

== About this Document

=== How to Read this Document

This is the User Guide for the SCTP Daemon Dynamic (SDD). SDD was developed for the TTCN-3 Toolset with TITAN. This document should be read together with Product Revision Information <<_3, [3]>> and Function Specification <<_4, [4]>>.

=== Presumed Knowledge
The knowledge of the TTCN-3 language <<_1, [1]>> and the TITAN TTCN-3 Test Executor <<_10, [10]>> is essential.

=== References

[[_1]][1] ETSI ES 201 873-1 v.3.1.1 (2005-06) +
The Testing and Test Control Nota¬tion version 3. Part 1: Core Language

[[_2]][2] 1/198 17-CRL 113 200 Uen +
TITAN Installation Guide

[[_3]][3] 109 21-CNL 113 630-1 Uen +
SCTP Daemon Dynamic for TTCN-3 Toolset with TITAN, Product Revision Information

[[_4]][4] 155 17-CNL 113 630 +
SCTP Daemon Dynamic for TTCN-3 Toolset with TITAN, Function Specification

[[_5]][5] 198 17-CNL 113 531 Uen +
IPL4 Test Port for TTCN-3 Toolset with TITAN, User’s Guide

[[_6]][6] 109 21-CNL 113 384 Uen +
Abstract Socket Test Port for TTCN-3 Toolset with TITAN, PRI

[[_7]][7] 109 21-CNL 113 686 Uen +
Socket API for TTCN-3 Toolset with TITAN, PRI

[[_8]][8] 109 21-CNL 113 531 Uen +
IPL4 Test Port for TTCN-3 Toolset with TITAN, PRI

[[_9]][9] 1/198 17-CRL 113 200 Uen +
TITAN User’s Guide

[[_10]][10] 2/198 17-CRL 113 200 Uen +
Programmer’s Technical Reference for TITAN

[[_11]][11] 109 21-CNL 113 472-7 Uen +
TCC Useful Functions for TTCN-3 Toolset with TITAN, Product Revision Information

[[_12]][12] 109 21-CNL 113 684-1 Uen +
SGsAP v9.0.0 Protocol Modules for TTCN-3 Toolset with TITAN, PRI

=== Abbreviations

RTE:: Run-Time Environment
SCTP:: Stream Control Transmission Protocol
SDD:: SCTP Daemon Dynamic
SUT:: System Under Test
TCP:: Transmission Control Protocol
TTCN-::  	Testing and Test Control Notation version 3

=== Terminology

SDD:: SCTP Daemon Dynamic, the abbreviation of this product.

== System Requirements

In order to operate SDD, the following system requirements must be satisfied:

* TITAN TTCN-3 Test Executor version R7A (1.7.pl0) or higher installed. For installation guide see <<_2, [2]>>.
* IPL4asp Test Port for TITAN ‎<<_8, [8]>>.
* TCCUsefulFunctions for TITAN ‎<<_11, [11]>>.

= The SCTP Daemon Dynamic

== Overview

SDD provides the following features to a testcase:

* Defining server and client associations
* SCTP payload relaying from the SUT via TCP connections between SDD and the testcases
* Keeping connected associations alive between testcases
* Reconnect disconnected client associations
* Dynamically create new SCTP client and server associations from the testcase
* Close client and server associations from the testcase
* Subscribe to association events, if the associations are already present
* API to allow automatic handling of incoming messages (i.e. heartbeat messages) and events
* Function callbacks that allow the user to extend the daemon so that routing can be implemented based on upper layer protocols
* Automatic shutdown after an inactivity period

The outline of SDD’s architecture can be seen in <<figure-1, Figure 1>>. SDD is a standalone application, which is executed independently of the TTCN-3 testcases. This results that the SCTP associations remain active between the executions of testcases.

When SDD is started, it connects the configured client SCTP associations to the SUT, opens the configured server SCTP associations, and starts listening on a TCP port for incoming connection requests from the users (testcases). After the daemon accepted a TCP connection request, the SCTP messages sent by the testcase are forwarded to the selected SCTP association. Naturally, the answers coming from the SUT are relayed back to the user as well. Thus, SDD provides an interface to access SCTP communication ports via TCP connections.

The daemon tries to re-establish client SCTP associations that were interrupted and the testcases are notified if the corresponding SCTP association is lost or becomes active again.

[[figure-1]]
image::images/architecture.png[title="SCTP Daemon Dynamic architecture"]

== Installation

SDD is used as part of the TTCN-3 test environment. This means that the TTCN-3 Test Executor must be installed before any operation of SDD. For more details on the installation of TTCN-3 Test Executor see <<_2, [2]>>.

Furthermore, SDD uses the IPL4 ‎<<_8, [8]>> test ports and interface functions from TCCUsefulFunctions ‎<<_11, [11]>>, therefore their installation is also inevitable.

== Compilation

SDD sources have to be compiled in order to get the SCTP Daemon Dynamic executable.  The compilation has to be done in single mode (`TTCN3_LIB=ttcn3` in the Makefile), not in parallel mode. The following SDD specific source files are needed:

* __SCTP_Daemon_Dynamic.ttcn__
* __SCTP_Daemon_Dynamic_Interface_Definitions.ttcn__
* __SCTP_Daemon_Dynamic_Types.ttcn__
* __SCTP_Daemon_Dynamic_IPL4_CtrlFunct.ttcn__
* __SCTP_Daemon_Dynamic_IPL4_CtrlFuncDef.cc__

The following source files are needed from other products:

* *IPL4asp Test Port for TITAN (CNL 113 531) ‎<<_8, [8]>>*

** __IPL4asp_PT.hh__
** __IPL4asp_PT.cc__
** __IPL4asp_PortType.ttcn__
** __IPL4asp_Types.ttcn__
** __IPL4asp_Functions.ttcn__
** __IPL4asp_protocol_L234.hh__
** __IPL4asp_discovery.cc__

* *Abstract Socket Common Component (CNL 113 384) ‎<<_6, [6]>>*
** __Abstract_Socket.cc__
** __Abstract_Socket.hh__

* *Socket API Common Component (CNL 113 686) ‎<<_7, [7]>>*
* *TCCUsefulFunctions for TITAN (CNL 113 472) ‎<<_11, [11]>>*
** __TCCInterface.cc__
** __TCCInterface_Functions.ttcn__
** __TCCInterface_ip.h__

`CPPFLAGS` are needed to be add in the Makefile:

* SCTP support need to be enabled by adding `-DUSE_SCTP`
* In lkstp version 1.0.7 or higher, the flag `-DLKSCTP_1_0_7`
* `-DSCTP_REPORT_LISTEN_RESULT`

For details on the compilation with TTCN-3 Test Executor see the relevant section of <<_10, [10]>>.

== Start procedure

SDD can be started as a stand-alone TTCN-3 program in single mode: __SCTP_Daemon_Dynamic <config file>.cfg__
Multiple instances of SDD can be executed in a single host.

If a fatal error occurs during initialization, SDD does not start. Fatal error means: the configuration file cannot be found or there is error in the RTE configuration file.

== Stop procedure

SDD can be stopped by pressing `CTRL-C`. The SCTP and TCP connections should gracefully terminate when SDD terminates.

== Configuration

SDD can be configured using the RTE configuration file, see ‎<<_10, [10]>>. This file is read by SDD at start-up and it sets its internal parameters. Any name can be chosen as RTE configuration file name, but it is recommended to have _.cfg_ as its extension.

=== SDD parameters

SDD’s own parameters have to be specified in the `[MODULE_PARAMETERS]` section of the RTE configuration file:

* `tsp_SDD_TCP_ListenInterface`
+
Optional
+
Type: charstring
+
Default value: `_"127.0.0.1"_`
+
This module parameter specifies the TCP interface where SDD is waiting for the clients to connect.

* `tsp_SDD_TCP_ListenPort`
+
Optional
+
Type: integer
+
Default value: `_1314_`
+
Specifies the TCP port where SDD is waiting for the clients to connect.

* `tsp_SDD_AssociationList`
+
Optional
+
Type: SDD_AssociationConfigList
+
Default value: empty
+
Specifies the list of associations to be initiated on the start-up of SDD.
+
Fields of a single `SDD_AssociationConfig`:

** `serverAssociation`
+
`_true_` means server, `_false_` means client.

** `autoReconnect`
+
`_true_` means reconnect association if it gets broken.

** `localInterface`
+
Local interface and port of the association. This field has to be filled if server association is created.

** `remoteInterface`
+
Remote interface and port of the association, This field has to be filled if client association is created.

* `tsp_SDD_ReconnectTimer`
+
Optional
+
Type: float
+
Default value: `_2.0_`
+
Specifies the interval (seconds) the daemon tries to re-establish a broken client association, if the association is configured to be auto-reconnected.

* `tsp_SDD_InactivityTimer`
+
Optional
+
Type: float
+
Default value: `_60.0_`
+
Specifies the timeframe (seconds) SDD is alive after a SCTP event. SDD exits to the shell if no event happens within this timeframe.
+
This feature is added to prevent cases when the SCTP client association gets invalid (the SUT is stopped) but there is no `COMM_LOST` indication about it.
+
The feature can be switched off by setting the parameter to `_0.0_` or a negative float value.

* [[tsp_debug]]`tsp_debug`
+
Optional
+
Type: boolean
+
Default value: `_false_`
+
A boolean parameter, which turns on/off the verbose output to the logfile. +
A sample module parameter setting can be examined <<rte-configuration-file, here>>, where a complete configuration file is presented.

=== IPL4 Test Port parameters in the RTE configuration file

SDD uses the IPL4 Test Port and therefore the `[TESTPORT_PARAMETERS]` section of the RTE configuration file shall contain the following parameters for the daemonPort port:

* `socket_debugging`
+
Optional
+
If set to `_"YES"_` the TCP Test Port outputs debug information. If set to `_"NO"_` the TCP Test Port outputs no debug information. The default value is `_"NO"_`. It is recommended to set this parameter to `_"NO"_` to avoid generating large amount of debug information.

* `use_connection_ASPs`
+
Mandatory
+
Its value has to be `_"YES"_`. This parameter tells the TCP port not to open any server socket or client connection by default. SDD performs opening the server socket dynamically on start-up, using TCP connection ASPs.

* `packet_hdr_length_offset`
+
Mandatory
+
If there is a protocol above TCP this parameter can be used to specify the offset (in bytes) in the protocol header where the length field starts. The test port uses this parameter to wait for a complete upper layer protocol message. This parameter should be used together with `packet_hdr_byte_order` and `packet_hdr_nr_bytes_in_length`.
+
Its value must be `_"2"_`.
+
WARNING: DO NOT CHANGE THIS SETTING!

* `packet_hdr_nr_bytes_in_length`
+
Mandatory
+
If there is a protocol above TCP this parameter can be used to specify the length of the length field (in bytes) in the protocol header. The test port uses this parameter to wait for a complete upper layer protocol message. This parameter should be used together with `packet_hdr_length_offset` and `packet_hdr_byte_order`.
+
Its value must be `_"2"_`.
+
WARNING: DO NOT CHANGE THIS SETTING!

* `packet_hdr_byte_order`
+
Mandatory
+
If there is a protocol above TCP this parameter can be used to specify the byte order of the protocol. The possible values are: MSB or LSB. The test port uses this parameter to wait for a complete upper layer protocol message. This parameter should be used together with `packet_hdr_length_offset` and `packet_hdr_nr_bytes_in_length`.
+
Its value must be `_"MSB"_`.
+
WARNING: DO NOT CHANGE THIS SETTING!

* `extendedPortEvents`
+
Optional
+
This parameter can be used to turn on extended port events. If extended portevents are set to `_"YES"_` state, the result of connection open, connection close, listening or various errors will be send in result type port events too.

The `[TESTPORT_PARAMETERS]` section of the RTE configuration file shall contain the following parameters for the `SCTP_PCO` port:

* `extendedPortEvents`
+
Optional
+
This parameter can be used to turn on extended port events. If extended portevents are set to `_"YES"_` state, the result of connection open, connection close, listening or various errors will be send in result type port events too.

Other optional IPL4 port parameters are listed in ‎<<_8, [8]>>.

== Logging

The logging mechanism logs information either to the log file or to the output console.  The user can set the amount and type of logging in the RTE configuration file. The Titan parameters `ConsoleMask` and `FileMask` control the overall logging. These logging options are described in <<_11, [11]>>.

SDD log messages can be received by using the TTCN_USER log mask.  The module parameter <<tsp_debug, `tsp_debug`>> enables/disables verbose logging. If `tsp_SDD_debug` is selected most internal events are logged textually.

Since there is only an MTC and no PTCs within SDD, there is only one log file that includes logging from SDD and the IPL4 Test Port.

== Error handling

Erroneous behaviour detected during runtime is directed into the RTE log file. The following two types of messages are taken care of:

* Errors: information about the detected errors is provided. If an error occurs the execution of SDD will stop immediately. The test ports will be unmapped. These log messages are starting with: `\*** ERROR`.
* Warnings: information about the detected warnings is provided. The execution continues after the warning is shown. These log messages are starting with: `\*** WARNING`.


The following sections give detailed descriptions of SDD’s error and warning messages. Please note, that besides these, error and warning messages of the IPL4asp test ports may also appear, since the daemon uses these components. For further information on them see the corresponding user’s guide ‎<<_8, [8]>>.

=== Error messages

* *`ERROR: Could not send data on the TCP between the testcase and the SCTP Daemon!`*
+
Check the TCP connection state between SDD and the testcase.

* *`ERROR: SCTP Daemon Dynamic failed to acquire TCP port #<listenPort> resource is not available`*
+
Most probably another instance of SDD is running on the same machine, occupying the same TCP listening port.

* *`ERROR: Unhandled daemon message received.`*
+
The handling of the message is not implemented in SDD.

=== Warning messages

* *`WARNING: more than one reconnecting association found.`*
+
SDD assumes that only one association is initiated at a time. There can be situations when more associations are getting
reconnected. In this case the first reconnecting association will be assigned to the socket returned by the SCTP port.

* *`WARNING: no reconnecting association found when processing <result>`*
+
SDD received a Result from the SCTP port, but none of the associations can be assigned to it.

* *`WARNING: test case <id> is already subscribed to: <association>`*
+
The test case issuing the `subscribeToAssociation` message is already subscribed to the given association’s events.

* *`WARNING: test case <id> was not subscribed to any association!`*
+
Either the testcase was already subscribed to the association (and the previous warning is also in the log), or the given
association was not found in the database.

* *`WARNING: SCTP server association <interface, port> is already listening!`*
+
The server association sent in the listen message is already in listening state, the server is active.

* *`ERROR: SCTP server association #<id> is declared as server, but has no localInterface defined!`*
+
The `localInterface` field is missing from the association, which is mandatory to define a server.

* *`ERROR: SCTP association <interface, port> has no remoteInterface defined, and it is not a server association!`*
+
The association is has no `remoteInterface` defined, and it is not a server association either. One of the two parameters
is wrong. The association can not be used with the current parameters.

* *`WARNING: SCTP association to <interface, port> is already active!`*
+
The reconnected association is already connected.

* *`ERROR: SCTP association to delete: <id> was not found in the database.`*
+
The given association was not found in the database.

= Dynamic behaviour

This section describes the communication between a testcase and the SUT through the SCTP Daemon Dynamic.

The __SCTP_Daemon_Dynamic_Test.ttcn__ in the demo directory of SDD contains example testcases for the usage of the daemon.

== Daemon messages and port definition

The `SCTP_Daemon_Dynamic_Interface_Definitions` module contains the required message types and port definition needed to communicate with SDD. The `SDD_Interface_PT` port type is a TCP port, which is responsible to establish the connection between the testcase and SDD.

The port is based on the TCP port, and automatically encodes/decodes the `SDD_Message_with_ClientId` type. The `SDD_Message_with_ClientId` type’s `msg` field is defined as a union, and contains all the possible interface messages which can be exchanged by the testcase and SDD.

[cols="m,s,",options="header"]
|===
|Message type |Direction |Effect
|SDD_SCTPData |Testcase↔SDD |SCTP data coming from the SUT is forwarded to the testcase, message coming from the testcase is forwarded to the SUT.
|SDD_QueryAssociations |Testcase→SDD |The testcase queries the current SCTP associations allocated in SDD.
|SDD_Listen |Testcase→SDD |SDD opens a new SCTP server socket, and subscribes the testcase to receive events from the server socket and the connected clients.
|SDD_Connect |Testcase→SDD |SDD initiates a client SCTP association to the SUT, and subscribes the testcase to the events of the SCTP association.
|SDD_Close |Testcase→SDD |If the requested SCTP association is client, SDD closes it. If server, then SDD shuts it down.
|SDD_SubscribeToAssociation |Testcase→SDD |SDD subscribes the testcase to the specified SCTP association’s events.
|SDD_Result |Testcase←SDD |Returns the result of a listen/connect request. The result will contain the allocated SCTP association ID, which is `_-1_` if failure happened.
|SDD_Associations |Testcase←SDD |Returns the current SCTP associations allocated in SDD in response to the `queryAssociations` request.
|SDD_AssociationChanged |Testcase←SDD |Reports about the state change of an SCTP association to the subscribed testcases.
|SDD_Connected |Testcase←SDD |Reports that the SUT has initiated a client connection to a server which the testcase is subscribed to.
|===

== Signalling procedures between the testcase and SDD

The signalling procedures are presented in this section in the recommended order as they should be performed in testcases.

[[connecting-the-testcase-to-sdd]]
=== Connecting the testcase to SDD

The `f_IPL4_connect` function can be used to create a connection. The connection ID is returned in the `Result` record.

As only the upper protocol may know how to find message boundaries in the stream of bytes. In order to perform this task a callback function may be registered for each connection in the test port. This way the user will receive complete messages.

To achieve this functionality, separate function(s) have to be written, which is needed to be called with the connection ID from the `Result` record.

[source]
f_IPL4_setGetMsgLen(inout SDD_Interface_PT portRef, in ConnectionId id := -1,inout f_getMsgLen f,in ro_integer msgLenArgs);

In the demo directory there is an example of usage.

=== Initiating server SCTP association

The purpose of the procedure is to ensure that an SCTP server association is active in SDD, and the testcase is subscribed to the SCTP server’s events. +
After successfully performing the procedure, the testcase knows the association ID of the SCTP server.

The procedure assumes that <<connecting-the-testcase-to-sdd, Connecting the testcase to SDD>> is performed successfully already.

image::images/Initiating_server_associations.png[title="Initiating server associations"]

=== Initiating client SCTP association

The purpose of the procedure is to ensure that an SCTP client association is active in SDD, and the testcase is subscribed to the SCTP client’s events.

After successfully performing the procedure, the testcase knows the association ID of the SCTP client.

The procedure assumes that <<connecting-the-testcase-to-sdd, Connecting the testcase to SDD>> is performed successfully already.

image::images/Initiating_client_associations.png[title="Initiating client associations"]

=== Querying the server’s connected client associations

The purpose of the procedure is to get the association IDs of the clients which are connected to SCTP servers active in SDD, and subscribe to their events.

After successfully performing the procedure, the testcase knows the association IDs of the connections connected to the SCTP servers.

The procedure assumes that <<connecting-the-testcase-to-sdd, Connecting the testcase to SDD>> is performed successfully already.

image::images/Querying_connected_client_associations.png[title="Querying connected client associations"]

== Sending SCTP data through SDD

Sending SCTP payload through SDD is performed by using the `SDD_SCTPData message`. SDD forwards the data to the association’s SCTP socket to the SUT.

image::images/Sending_SCTP_payload.png[title="Sending SCTP payload"]

== Receiving SCTP data through SDD

Receiving SCTP payload through SDD is performed by handling the incoming `SDD_SCTPData message` in an altstep. SDD forwards the data coming on the association’s SCTP socket to the testcase.

image::images/Receiving_SCTP_payload.png[title="Receiving SCTP payload"]

== Receiving SCTP association events

SCTP association state change events can are sent to the testcase with the `SDD_AssociationChanged` message.

image::images/Receiving_SCTP_association_events.png[title="Receiving SCTP association events"]

== Notification of incoming SCTP client connection

When a SCTP client connects to the server allocated in SDD, SDD sends the `SDD_Connected` message to the testcase, which includes the association ID of the accepted client connection.

image::images/Incoming_client_connection.png[title="Incoming client connection"]

== Closing SCTP associations

The testcase can close any SCTP association by sending the `SDD_Close` message.

image::images/Closing_an_association.png[title="Closing an association"]

[[automatic-message-handling]]
= Automatic message handling

SDD provides a method for automatically handling incoming SCTP messages (like protocol heartbeat messages) and answer them without relaying them to the testcase. +
To achieve this functionality, separate function(s) have to be written, which will be executed when SCTP data arrives from the SUT.

The `SCTP_Daemon_Dynamic_Types` module defines the function prototype:

[source]
----
type function f_SDD_AutoReplyFunction(in integer associationIndex, in ASP_RecvFrom sctpReceived, out ASP_Send sctpReply) runs on self return boolean;
----

The `f_RegisterAutoReplyFunction(in f_SDD_AutoReplyFunction autoReplyFunction)` function of the `SCTP_Daemon_Dynamic` module has to be used to register auto-reply function(s) of type `f_SDD_AutoReplyFunction`.

The logic displayed in <<flowchart-of-automatic-reply-logic, Figure 10>> is be applied if any `SCTP_DATA` is received from the SUT.

[[flowchart-of-automatic-reply-logic]]
image::images/Flowchart_of_automatic_reply_logic.png[title="Flowchart of automatic reply logic"]

The user-written auto-reply function runs on the SDD’s component. The parameter `associationIndex` can be used as an index to the SDD’s internal association databases.

The function has to examine the incoming message, and if decides to answer it, it sets the answer in the `sctpReply` parameter, and returns `_true_`. The returned `_true_` value means that the incoming message is processed, and SDD should not forward it to the testcase but send the `sctpReply` to the SUT.

If the auto-reply function decides that the message should be relayed to the testcase, it has to return `_false_` on exit.

To make the functionality working, the user has to write a module with a separate testcase, which registers the auto-reply function(s), and executes the SDD’s `f_SDD()` function.

For a working example, see the __SCTP_Daemon_Dynamic_with_DiameterAutoReplies.ttcn__ source file in the demo directory of SDD.

= Automatic event handling

SDD provides a method for automatically handling incoming SCTP events (association state changes) and send a SCTP message on them without relaying them to the testcase. +
The API can be used to implement automatic sending of upper layer messages when the state of the associations changes.
To achieve this functionality, separate function(s) have to be written, which will be executed when the association event happens.

The `SCTP_Daemon_Dynamic_Types` module defines the function prototype:

[source]
----
type function f_SDD_AutoStateChangeHandlerFunction(in integer associationIndex, in SAC_STATE newState, out ASP_Send sctpMsg) runs on self return boolean;
----

The `f_RegisterAutoStateChangeHandlerFunction (in f_SDD_AutoStateChangeHandlerFunction autoStateChangeHandlerFunction)` function of the `SCTP_Daemon_Dynamic` module has to be used to register auto-event function(s) of type `f_SDD_AutoStateChangeHandlerFunction`.

The logic and the required implementation is the same as in <<automatic-message-handling, Automatic message handling>>. Example implementation can be found in the __SCTP_Daemon_Dynamic_with_DiameterAutoReplies.ttcn__ source file in the demo directory of SDD.

= Routing based on upper level protocol

In case several clients want to use the same SCTP association, but would like to receive the answers that only applies to them, the SCTP daemon can be extended with routing call back functions that will allow the daemon to route the messages to the TCP clients based on some application protocol fields.

As an example the SGsAP ‎<<_12, [12]>> application protocol case is described here. The daemon has two interfaces the behaviour for each is the following:

* The daemon has a TCP server socket where client PTCs can connect to. On this interface the clients can send encoded `PDU_SGsAP` messages and control ASPs. When an encoded `PDU_SGsAP` message arrives to the daemon it decodes it and extracts the IMSI from the message and it saves the connection identifier of the client PTC in a database, where the key to insert is the IMSI. Next it encodes the PDU and sends out the message on its SCTP interface. When a client TCP connection is closed, the daemon will remove all the IMSI keys from its database that belong to that TCP client connection.

* The daemon maintains an SCTP association to the SUT on its SCTP interface. When a message arrives on this interface it decodes it. It extracts the IMSI. Using the IMSI as key, it looks up the client TCP connection identifier from its internal database and will forward the encoded message to the client PTC. In case the message doesn't contain an IMSI (e.g. `sGsAP_STATUS`, `sGsAP_RESET_ACK`, `sGsAP_RESET_INDICATION`) the message is sent to all the clients that sent SGsAP messages before.

Now it is possible to register in 3 functions into the daemon:

* `v_Connection_Insert: type function Connection_Insert(octetstring pl_data, integer pl_id)`
+
If this function reference is not null, then it is called when there is an incoming `sctpData` ASP on the TCP interface.

** `pl_data`: the incoming payload
** `pl_id`: the TCP connection identifier
* `v_Connection_Lookup: type function Connection_LookUp(octetstring pl_data) returns Integer_List`
+
If this function reference is not null, then it is called when there is an incoming ASP on the SCTP interface.

** `pl_data`: the incoming payload
** `Integer_List`: List of TCP connections where the payload will be forwarded
* `v_Connection_Delete: type function Connection_Delete(integer pl_id)`
+
If this function reference is not null, then it is called when a TCP connection is closed.

** `pl_id`: the TCP connection id of the closed connection

The SGsAP SCTP Daemon is implemented as an extension of the SCTP Dynamic Daemon. The functions above are implemented for SGsAP. The implementation is available in the demo directory in the following files:

* __SGsAP_SCTP_Daemon.ttcn__
* __SGsAP_SCTP_Daemon_Types.ttcn__
* __SGsAP_SCTP_Daemon.cfg__

= Examples

[[rte-configuration-file]]
== RTE Configuration file

[source]
----
[MODULE_PARAMETERS]
// Host name where the SCTP Daemon listens for the testcases
tsp_SDD_TCP_ListenInterface := "127.0.0.1";
// Port number where the SCTP Daemon listens for the testcases
tsp_SDD_TCP_ListenPort := 1314;
// Default set of SCTP connections which the SCTP Daemon initializes on startup
// for associations with autoReconnect == true and server associations
tsp_SDD_AssociationList := {
  {
    serverAssociation := true, // true := server, false: client
    autoReconnect := false,
    localInterface := {
      hostNameLength := 0,     // does not matter here
      hostName := "127.0.0.1",
      portNumber :=  1315
    },
    remoteInterface := omit
  },
  {
    serverAssociation := false, // true := server, false: client
    autoReconnect := true,
    localInterface := omit,
    remoteInterface := {
      hostNameLength := 0,      // does not matter here
      hostName := "127.0.0.1",
      portNumber := 1315        // loopback association to our server
    }
  }
};

tsp_SDD_ReconnectTimer := 2.0;
tsp_SDD_InactivityTimer := 200.0;
tsp_SDD_debug := false;


[LOGGING]
LogFile := "sctp_daemon_dynamic.log"
FileMask := WARNING|TIMEROP|PORTEVENT|PARALLEL|FUNCTION|DEFAULTOP|ACTION|VERDICTOP|USER|TESTCASE|STATISTICS|EXECUTOR|ERROR
LogSourceInfo := single

[TESTPORT_PARAMETERS]
*.*.extendedPortEvents := “YES”
*.daemonPort.use_connection_ASPs := "YES"
*.daemonPort.packet_hdr_length_offset := "2"
*.daemonPort.packet_hdr_nr_bytes_in_length := "2"
*.daemonPort.packet_hdr_byte_order := "MSB"

[EXECUTE]
SCTP_Daemon_Dynamic.tc_SDD
7.2	Makefile

# The following make commands are available:
# - make, make all     Builds the executable test suite.
# - make archive       Archives all source files.
# - make check         Checks the semantics of TTCN-3 and ASN.1 modules.
# - make clean         Removes all generated files.
# - make compile       Translates TTCN-3 and ASN.1 modules to C++.
# - make dep           Creates/updates dependency list.
# - make objects       Builds the object files without linking the executable.
# - make tags          Creates/updates tags file using ctags.

#
# Set these variables...
#

# The path of your TTCN-3 Test Executor installation:
# Uncomment this line to override the environment variable.
# TTCN3_DIR =

# Your platform: (SOLARIS, SOLARIS8, LINUX, FREEBSD or WIN32)
PLATFORM = LINUX

# Your C++ compiler:
CXX = g++

# Flags for the C++ preprocessor (and makedepend as well):
CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)/include –DUSE_SCTP -DLKSCTP_1_0_7 –DSCTP_REPORT_LISTEN_RESULT

# Flags for the C++ compiler:
CXXFLAGS = -Wall

# Flags for the linker:
LDFLAGS =

# Flags for the TTCN-3 and ASN.1 compiler:
COMPILER_FLAGS = -L

# Execution mode: (either ttcn3 or ttcn3-parallel)
TTCN3_LIB = ttcn3

# The path of your OpenSSL installation:
# If you do not have your own one, leave it unchanged.
OPENSSL_DIR = $(TTCN3_DIR)

# The path of your libxml2 installation:
# If you do not have your own one, leave it unchanged.
XMLDIR = $(TTCN3_DIR)

# Directory to store the archived source files:
# Note: you can set any directory except ./archive
ARCHIVE_DIR = backup

#
# You may change these variables. Add your files if necessary...
#
# TTCN-3 modules of this project:
TTCN3_MODULES = TCCInterface_Functions.ttcn Socket_API_Definitions.ttcn SCTP_Daemon_Dynamic_with_DiameterAutoReplies.ttcn SCTP_Daemon_Dynamic_Types.ttcn SCTP_Daemon_Dynamic_Interface_Definitions.ttcn SCTP_Daemon_Dynamic_IPL4_CtrlFunct.ttcn SCTP_Daemon_Dynamic.ttcn IPL4asp_Types.ttcn IPL4asp_PortType.ttcn IPL4asp_Functions.ttcn

# ASN.1 modules of this project:
ASN1_MODULES =

# C++ source & header files generated from the TTCN-3 & ASN.1 modules of
# this project:
GENERATED_SOURCES = TCCInterface_Functions.cc Socket_API_Definitions.cc SCTP_Daemon_Dynamic_with_DiameterAutoReplies.cc SCTP_Daemon_Dynamic_Types.cc SCTP_Daemon_Dynamic_Interface_Definitions.cc SCTP_Daemon_Dynamic_IPL4_CtrlFunct.cc SCTP_Daemon_Dynamic.cc IPL4asp_Types.cc IPL4asp_PortType.cc IPL4asp_Functions.cc
GENERATED_HEADERS = TCCInterface_Functions.hh Socket_API_Definitions.hh SCTP_Daemon_Dynamic_with_DiameterAutoReplies.hh SCTP_Daemon_Dynamic_Types.hh SCTP_Daemon_Dynamic_Interface_Definitions.hh SCTP_Daemon_Dynamic_IPL4_CtrlFunct.hh SCTP_Daemon_Dynamic.hh IPL4asp_Types.hh IPL4asp_PortType.hh IPL4asp_Functions.hh

# C/C++ Source & header files of Test Ports, external functions and
# other modules:
USER_SOURCES = TCCInterface.cc SCTP_Daemon_Dynamic_IPL4_CtrlFuncDef.cc IPL4asp_discovery.cc IPL4asp_PT.cc Abstract_Socket.cc
USER_HEADERS = TCCInterface_ip.h IPL4asp_protocol_L234.hh IPL4asp_PT.hh Abstract_Socket.hh

# Object files of this project that are needed for the executable test suite:
OBJECTS = $(GENERATED_OBJECTS) $(USER_OBJECTS)

GENERATED_OBJECTS = TCCInterface_Functions.o Socket_API_Definitions.o SCTP_Daemon_Dynamic_with_DiameterAutoReplies.o SCTP_Daemon_Dynamic_Types.o SCTP_Daemon_Dynamic_Interface_Definitions.o SCTP_Daemon_Dynamic_IPL4_CtrlFunct.o SCTP_Daemon_Dynamic.o IPL4asp_Types.o IPL4asp_PortType.o IPL4asp_Functions.o

USER_OBJECTS = TCCInterface.o SCTP_Daemon_Dynamic_IPL4_CtrlFuncDef.o IPL4asp_discovery.o IPL4asp_PT.o Abstract_Socket.o

# Other files of the project (Makefile, configuration files, etc.)
# that will be added to the archived source files:
OTHER_FILES = ../SCTP_Daemon_Dynamic.cfg Makefile

# The name of the executable test suite:
TARGET = SDD

#
# Do not modify these unless you know what you are doing...
# Platform specific additional libraries:
#
SOLARIS_LIBS = -lsocket -lnsl -lxml2
SOLARIS8_LIBS = -lsocket -lnsl -lxml2
LINUX_LIBS = -lxml2
FREEBSD_LIBS = -lxml2
WIN32_LIBS = -lxml2

#
# Rules for building the executable...
#

all: $(TARGET) ;

objects: $(OBJECTS) ;

$(TARGET): $(OBJECTS)
	$(CXX) $(LDFLAGS) -o $@ $(OBJECTS) \
	-L$(TTCN3_DIR)/lib -l$(TTCN3_LIB) \
	-L$(OPENSSL_DIR)/lib -lcrypto \
	-L$(XMLDIR)/lib $($(PLATFORM)_LIBS) \
	|| $(TTCN3_DIR)/bin/titanver $(OBJECTS)

.cc.o .c.o:
	$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) -o $@ $<

$(GENERATED_SOURCES) $(GENERATED_HEADERS): compile
	@if [ ! -f $@ ]; then rm -f compile; $(MAKE) compile; fi

check: $(TTCN3_MODULES) $(ASN1_MODULES)
	$(TTCN3_DIR)/bin/compiler -s $(COMPILER_FLAGS) \
	$(TTCN3_MODULES) $(PREPROCESSED_TTCN3_MODULES) $(ASN1_MODULES)

compile: $(TTCN3_MODULES) $(ASN1_MODULES)
	$(TTCN3_DIR)/bin/compiler $(COMPILER_FLAGS) \
	$(TTCN3_MODULES) $(ASN1_MODULES) - $?
	touch $@

browserdata.dat: $(TTCN3_MODULES) $(ASN1_MODULES)
	$(TTCN3_DIR)/bin/compiler -B -s $(COMPILER_FLAGS) \
	$(TTCN3_MODULES) $(ASN1_MODULES)

tags: $(TTCN3_MODULES) $(ASN1_MODULES) \
$(USER_HEADERS) $(USER_SOURCES)
	$(TTCN3_DIR)/bin/ctags_ttcn3 --line-directives=yes \
	$(TTCN3_MODULES) $(ASN1_MODULES) \
	$(USER_HEADERS) $(USER_SOURCES)

clean:
	-rm -f $(TARGET) $(OBJECTS) $(GENERATED_HEADERS) \
	$(GENERATED_SOURCES) compile \
	browserdata.dat tags *.log

dep: $(GENERATED_SOURCES) $(USER_SOURCES)
	makedepend $(CPPFLAGS) -DMAKEDEPEND_RUN $(GENERATED_SOURCES) $(USER_SOURCES)

archive:
	mkdir -p $(ARCHIVE_DIR)
	tar -cvhf - $(TTCN3_MODULES) $(ASN1_MODULES) \
	$(USER_HEADERS) $(USER_SOURCES) $(OTHER_FILES) \
	| gzip >$(ARCHIVE_DIR)/`basename $(TARGET) .exe`-`date '+%y%m%d-%H%M'`.tgz

diag:
	$(TTCN3_DIR)/bin/compiler -v 2>&1
	$(TTCN3_DIR)/bin/mctr_cli -v 2>&1
	$(CXX) -v 2>&1
	@echo TTCN3_DIR=$(TTCN3_DIR)
	@echo OPENSSL_DIR=$(OPENSSL_DIR)
	@echo XMLDIR=$(XMLDIR)
	@echo PLATFORM=$(PLATFORM)

#
# Add your rules here if necessary...
#
----