TNSDL

TNSDL stands for TeleNokia Specification and Description Language. TNSDL is based on ITU-T SDL-88 language. It is used exclusively at Nokia Siemens Networks for developing applications for telephone exchanges.

Purpose

TNSDL is a generic purpose procedural programming language. It is specially suited for developing highly concurrent, distributed applications.

It was originally designed for programming circuit switched exchanges. As the world shifted towards packet switched and internet-based telecommunication, TNSDL turned out to be a perfect tool for developing internet servers.

Design

TNSDL is a very simple, easy to learn programming language.

Basics

TNSDL is a strongly typed procedural programming language. Its basic capabilities are often compared to C and Pascal languages'.

Multi-processing

In TNSDL processes are created by CREATE command. It is somewhat similar to POSIX fork or pthread_create command. TNSDL CREATE command creates either an operating system process or cooperative task. It depends on settings how the new entity is created.

The source code itself does not reflect which scheduling method is used. Still, to avoid certain race conditions developers may need to be prepared for parallel execution. TNSDL explicitly supports critical sections to be marked in the code.

In case of cooperative multitasking a program is scheduled as one operating system process. When a cooperative thread enters the state of waiting for asynchronous input, another thread of the program may run.

Message passing

TNSDL supports actor model and processes to be designed as event-driven finite state machines. Inter-process communication is done by asynchronous message passing. OUTPUT command sends a message, while INPUT statements define the expected messages.

Timers, from TNSDL perspecive, are delayed messages. Just like ordinary messages, timer expiration is handled by INPUT statement. SET command starts and RESET command cancels a timer.

State machines can be optionally used so that not to process certain input messages at some stage of the processing.

The following code piece demonstrates a server, which receives a query signal (message), contacts a database process to obtain the necessary data and finally sends an answer signal.

DCL WITHWARMING /* Data to be live-migrated */
  query_process pid; /* PID of query_signal sender */
 
CONSTANT time_to_wait = 10; /* Timeout of database response */
 
TIMER db_timeout_timer; /* Timer of database response */
 
STATE idle; /* Idle state, wait for query signal */
  INPUT query_signal(DCL input_data);
    DCL
      db_query db_query_type;     /* Local variable, stored on stack. */
    TASK query_process := SENDER; /* Sender address saved to specific memory area, which is preserved even on software update.*/
    TASK db_query.field1 := some_procedure(input_data),
         db_query.field2 := input_data.field1;
    OUTPUT db_request_signal(db_query) TO db_process; /* Send request to database process */
    SET(NOW + time_to_wait, db_timeout_timer);        /* Start database response timer */
    NEXTSTATE wait_db;                                /* Enter wait_db state where database response is expected */
ENDSTATE idle;
 
STATE wait_db;
  INPUT db_response_signal(DCL answer_data);
    RESET(db_timeout_timer) COMMENT 'Database answered in time';
    OUTPUT answer_signal(answer_data.records) TO query_process;
    NEXTSTATE idle;
 
  INPUT db_timeout_timer; /* Timeout */
    OUTPUT error_signal(error_constant) TO query_process;
    NEXTSTATE idle;
ENDSTATE wait_db;

Comments:

• State machine prevents any new query_signal to be processed while waiting for database program answer.
• WITHWARMING means that when another computer takes over the role of the current computer, then copy that data (variable) to the new computer. Therefore if hardware change or software update happens while waiting for database answer, the address of the query sender is not lost and the answer can be delivered properly.

TNSDL allows inputs to be tied to several or all the states. An input signal may have state specific behavior, if needed.

STATE idle COMMENT 'Idle state';
  INPUT are_you_busy;
    OUTPUT no TO SENDER;
    NEXTSTATE -; /* No state change */
  /* ... other input handlers */
ENDSTATE idle;
 
STATE *(idle) COMMENT 'Any state, except idle';
  INPUT are_you_busy;
    OUTPUT yes TO SENDER;
    NEXTSTATE -; /* No state change */
ENDSTATE *(idle);
 
STATE * COMMENT 'Any state';
  INPUT are_you_alive;
    OUTPUT yes TO SENDER;
    NEXTSTATE -; /* No state change */
ENDSTATE *;

Compiling

TNSDL does not have a compiler. Instead, the code is translated to C language. The sole purpose of TNSDL is to make message handling, state machine definition and data warming easy to be coded. Processor specific optimization is the task of the C compiler used.

After translating TNSDL to C, generic C compilers, linkers, coverage measurement and profiling tools can be used. To make source level debugging possible TNSDL puts line number references to generated C code.

TNSDL code can call routines implemented in other languages, if objects or libraries are present for them. Even C language macros can be used, if C header files are present. Declarations must be made available for TNSDL translator.

TNSDL translator is a proprietary tool.

Use

TNSDL is commonly used on DX 200 and IPA 2800 platforms for high performance, high availability applications.

TNSDL is actively used and developed programming language used by thousands of developers (in 2010).

TNSDL is mainly used in Nokia Siemens Networks for developing software for SGSN, BSC etc.

History

1980s: At the beginning ITU-T SDL had a graphical syntax. Textual syntax was introduced later. Similarly, a graphical tool and code generator was developed within Nokia.

1990: ITU-T SDL shifted towards text-based representation. Based on SDL-88 specification TNSDL was born. TNSDL is a simplified and heavily customized variant of SDL-88.