TNSDL

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

Purpose

TNSDL is a general-purpose procedural programming language. It is especially well-suited for developing highly concurrent, distributed systems.[1]

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 an excellent fit for developing internet servers, too.

Design

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

Basics

TNSDL is a strongly typed procedural programming language. Its basic capabilities are comparable to the C and Pascal languages.

Multi-processing

In TNSDL processes are created by the CREATE command. (It is somewhat similar to the POSIX fork or pthread_create commands.) The CREATE command creates either an operating system process or a cooperative task.

The process model can be selected by configuration. 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 the actor model and processes are meant to be designed as event-driven finite state machines. Inter-process communication is done by asynchronous message passing. The OUTPUT command sends a message, while INPUT statements define the expected messages.

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

State machines can be optionally used, for example, to prevent accepting 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:

TNSDL allows inputs to be tied to several or all of 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 *;

Differences from SDL-88

Nokia has made several modifications to the language,[2] mainly including simplifications and additions, such as:

Compiling

TNSDL is not directly compiled to machine code. Instead, TNSDL programs are translated to C language source code. The responsibility of TNSDL is to allow message handling, state machine definitions, synchronizing parallel execution, "data warming" etc. easily and safely coded. The task of processor-specific code generation and low-level optimization is delegated to the C compiler used.

After translating TNSDL to C, any standard-compliant C compiler, linker, coverage measurement and profiling tool can be used. To make source-level debugging possible TNSDL puts line number references to the 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. External declarations must be made available to the TNSDL translator.

The TNSDL translator is a proprietary tool. A source code (reachability) analyser has also been developed specifically for TNSDL.[3]

Use

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

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

TNSDL is mainly used at Nokia Networks for developing software for SGSNs, BSCs, mobile switching centers, application servers etc.

History

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

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

References

  1. Jeannette M. Wing, Jim Woodcook, Jim Davies, ed. (1999). FM'99 - Formal Methods: World Congress on Formal Methods, 1999, Proceedings. Springer. ISBN 3540665870.
  2. Jyrinki, Tero (1997). "Dynamical analysis of SDL programs with Predicate/Transition nets". Helsinki University of Technology, Digital Systems Laboratory: 22.
  3. Husberg, Nisse; Malmqvist, Markus; Jyrinki, Tero (1996). "Emma: A Tool For Analysis of SDL Programs". CiteSeerX: 10.1.1.30.3240.
This article is issued from Wikipedia - version of the Tuesday, October 06, 2015. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.