Home
RECOMMENDED FOR YOU:
SMS Gateway software
Ozeki brings you outstanding
SMS Gateway technology. Use our SMS Server products on Windows,Linux, or Android

C# SMS API
Developers can use our C# SMS API to send SMS from C#.Net. The C# SMS API comes with full source code

PHP SMS API
The ozeki PHP SMS gateway software can be used to send SMS from PHP and to receive SMS usig PHP on your website

SMPP SMS Gateway
SMS service providers use our SMPP gateway solution, that offers a high performance SMPP server and SMPP client gateway with amazing routing capabilities
Ozeki NG SMS Gateway

TCP IP SMS connections

This guide explains why is TCP/IP a good choice for transfering SMS messages. Most IP SMS protocols, such as the SMPP Protocol, the CIMD2 protocol, the UCP protocol are based on TCP/IP. Read the following section to understand why.

What is TCP/IP

The TCP/IP protocol is used to setup bidirectional, reliable communication channels over the Internet. RFC 793 defines the TCP/IP standard. This RFC is maintained by the standardization body called IETF.

How is TCP/IP SMS connection created?

Transmission Control Protocol (TCP) is designed to be a bidirectional, ordered, and reliable data transmission protocol between two end points (programs). In this context, the term reliable means that it will retransmit the packets if it gets lost in the middle. TCP guarantees the reliability by sending back Acknowledgment (ACK) packets back for a single or a range of packets received from the peer. See the TCP state diagram (Figure 1).

Figure 1 - TCP/IP connection state diagam

How is TCP/IP SMS connection destroyed?

TCP is a bidirectional communication protocol, so when the connection is established, there is not a difference between the client and the server. Also, either one can call quits, and both peers needs to agree on closing to fully close an established TCP connection. This goes same for the control signals such as termination request/response.

Let's call the first one to call the quits as the active closer, and the other peer the passive closer. When the active closer sends FIN, the state goes to FIN-WAIT-1. Then it receives an ACK for the sent FIN and the state goes to FIN-WAIT-2. Once it receives FIN also from the passive closer, the active closer sends the ACK to the FIN and the state goes to TIME-WAIT. In case the passive closer did not received the ACK to the second FIN, it will retransmit the FIN packet.

RFC 793 sets the TIME-OUT to be twice the Maximum Segment Lifetime, or 2MSL. Since MSL, the maximum time a packet can wander around Internet, is set to 2 minutes, 2MSL is 4 minutes. Since there is no ACK to an ACK, the active closer can't do anything but to wait 4 minutes if it adheres to the TCP/IP protocol correctly, just in case the passive sender has not received the ACK to its FIN (theoretically).

In reality, missing packets are probably rare, and very rare if it's all happening within the LAN or within a single machine.

More information