In this section:
The interface between the SS7 and TCP/IP environments using the UAP is managed by doing the following:
Ribbon implements the UAP TCP/IP interface in the CMConnection class of the ptutil library.
The Nagle algorithm has been introduced to optimize TCP/IP network utilization for low-bandwidth applications. This algorithm delays the transmission of a packet until a sufficiently large transmit buffer is accumulated or until a certain period of time elapses. This time period is usually 200 milliseconds.
Due to the real-time nature of SS7 traffic, it is recommended that you disable the Nagle algorithm for socket communication with the DSC Platform. Failure to do so, introduces an unnecessary delay in the SS7 message flow.
On most UNIX-based platforms, you can disable the Nagle algorithm by issuing the following system call on the socket’s file descriptor:
/* set the TCP No-delay flag (disable Nagle algorithm) */ int flag = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
Most other languages and platforms have a similar feature (usually known as the TCP_NODELAY option).
By default, most operating systems provide a blocking interface for TCP/IP sockets. Although this interface may allow for an improved error recovery scheme, the blocking interface does impact the performance of the communication channel. For example, a system call such as send() with a blocking interface does not return until the operating system confirms that the message is successfully stored in the transmit buffer.
You can configure TCP/IP for a non-blocking interface to improve performance and support asynchronous events using the select() function call on a UNIX-based architecture.
To set up a non-blocking socket interface, use the following call on the newly created socket:
/* set the socket to non blocking */ fcntl( fd, F_SETFL, O_NONBLOCK );
Most other languages and platforms have a similar feature.
The original goal of TCP/IP was to provide a reliable connection-oriented session between two remote computers across a slow and unreliable network. In trying to achieve this goal, an elaborate retransmission scheme was designed and implemented. This retransmission scheme allows for network failures to be undetected under a no load situation, and ensures a retry period of up to 10 minutes when waiting for an acknowledgment for a transmitted message. The retransmission scheme is valuable for most applications such as http and ftp, but is insufficient for near real-time applications such as SS7 over TCP/IP.
A typical method for detecting network failures is to use a probing message that forces the remote system to provide an immediate response or heartbeat message. This message has been implemented in the core DSC Platform messages as part of the four-octet header defined in the next section. For more information, see Using a Message Header to Delimit Message Boundaries.
The nature of the sliding window acknowledgement scheme used in IP creates the possibility of fragmentation of messages at the TCP/IP level.
The sliding window is the method of flow control used by TCP. The purpose of the sliding window is to prevent the sender dispatching too many packets that would create an overflow in network resources or the receiver's buffer.
For example, a system may send 48 octets at once. The system on the receiving end may receive 16 octets, and then in a subsequent system call receive the remaining 32 octets. In another situation, a system may send two messages of 48 octets each by issuing two separate system calls, yet the receiving end receives a single 96-octet message.
To distinguish separate messages, every message sent between the DSC Platform and the IP application over TCP/IP is prefixed with a four-octet header that contains the type and length of the message that follows.
The Message Header is a four octet header that describes the nature and size of the content of the message that follows. The offsets are indicated in number of bytes from the beginning of the message. The format of the message header is shown in the following table.
The CMConnection class handles encoding and decoding of the Message Header transparently and TCP/IP for SS7 configuration by using the following options in the setOptions () function:
The Message Command sub-field contains the commands pertaining to the connection. As shown in the following table, these commands can be sent in either direction.