SMPP Asynchronous Mode

Posted by on Nov 9, 2010 in Support Blog

Topic Keywords: , ,

One of the biggest limitations to SMPP performance is protocol implementations that do not support SMPP asynchronous mode, or to state it more correctly, do not take advantage of the speed boost that is possible with SMPP asynchrnous mode.

SMPP Synchronous Mode = One Message at a Time

In SMPP Synchrnous mode, each side of the SMPP client has only one outstanding transaction active at a time. For example, when the client is submitting a message (SMPP submit_sm PDU), it waits to receive an acknowledgement from the server that the server has received the message (SMPP submit_sm_resp PDU) before the next message is submitted.

Depending on the network latency between SMPP client and server (e.g., use the round-trip time for a ping as a starting point), it may be difficult to exceed anywhere between 3 messages per second and 20 messages per second unless both client and server are located on the same local area network. The exact speed limit will vary depending on a combination of network latency, and how much processing is involved for the server to accept the message and generate the acknowledgement back to the client. Server load at that precise moment in time can also be a significant performance limiting factor.

With an average 50ms latency between client and server, it is not possible to exceed 20 messages per second in synchronous mode, and that is if the SMPP server is quick and immediately acts on the received messages, and is extremely efficient in returning its acknowledgement.

An average latency of 100ms lowers this limit to 10 messages per second.

In the real world, we’ve seen plenty of SMS service provider connections that top out at 3 to 5 messages per second using synchronous mode.

SMPP Asynchronous Mode = No wait Between Messages

SMPP Asynchrnous mode is the solution to this performance dilemma. Each side of the connection is free to send multiple transactions without waiting for a response to the first transaction. For example, a client may sumbit multiple messages to the SMSC (SMPP submit_sm PDU) before it receives any acknowledgments back (SMPP submit_sm_resp PDU).

SMPP Async mode is a windowing protocol. Most SMPP implementations will allow you to tune performance by specifying a maximum window size (maximum number of outstanding transactions before requiring a response to at least one of the outstanding transactions). In NowSMS, when configuring an SMPP SMSC connection, this is specified under the “Advanced Settings” for the properties of the SMPP connection. Look for “Enable SMPP Async Mode (windowing)” and the “Window Size (packets)” parameter.

SMPP Async mode sounds fantastic … so why don’t we use it all the time?

Well, the truth is that a lot of typical SMPP connections simply aren’t that fast. There’s a lot of SMPP software out there that can get tripped up by async mode. So it’s safest to start with synchronous mode, and verify that async mode can be supported.

There is also an issue that most SMS service provider connections have strict speed limits that clients cannot exceed. This is done by providers to help them manage and control the overall throughput of their entire system. If you submit messages faster than your SMS provider will allow, you will end up with throttling errors that end up significantly reducing your overall throughput. So in most cases, when using async mode, it is very important to know the SMS speed limit imposed by your SMS provider.

The article SMSC Speed Limits (https://nowsms.com/smsc-speed-limits) explains how to configure a speed limit for an SMPP (or other type of SMSC) connection with the SMSCSendLimit=x/y setting in the [SMPP – server:port] section of SMSGW.INI.

This speed limit setting is designed to work very well with SMPP Async mode to enable NowSMS to send messages as fast as your SMS provider connection (and NowSMS license) will allow. (x/y = x messages every y seconds, e.g., 58/1 = 58 messages per second, 125/2 = 125 messages every 2 seconds.)

It is also worth giving some guidance on window sizes. Our general recommendation is for the window size to approximate the target number of messages per second. This is a recommendation only, and not a requirement. Some SMSCs may react negatively to larger window sizes if they are under stress, so determining an optimal setting may require experimentation and monitoring of log files.

SMPP Async Mode When NowSMS is the SMPP Server

Thus far, all of our discussion of SMPP Async Mode has focused on NowSMS as an SMPP client, connecting to an SMPP server to send messages.

What if NowSMS is the SMPP server? Is it possible to use async mode to speed the pace of delivering SMS messages (especially delivery reports) to a connected client?

Historically, the SMPP implementation in NowSMS has only made use of async mode for connections where NowSMS is the client (NowSMS initiates the SMPP bind).

SMPP Async Mode support for NowSMS as an SMPP server has just been added in the v2010.11.04 update which is available for download at https://nowsms.com/download/nowsmsupdate.zip. (Note: This update link may be reused by a newer version in the future.  Newer versions will also include this functionality.)

SMPP Async Mode for the SMPP Server is not automatically enabled by default, as it may cause problems with some SMPP clients.

To enable SMPP Async Mode for all SMPP clients connecting to the NowSMS SMPP Server (not recommended for most installations), add SMPPServerAsyncWindowSize=## to the [SMSGW] section of SMSGW.INI. (## is the SMPP Async window size.) If this setting is not present, SMPP Async Mode is not enabled by default for the SMPP Server, but may be enabled for select client connections.

To individually enable or disable SMPP Async Mode for selected clients, add an [SMPPServerAsyncWindowSize] section to SMSGW.INI, and specify AccountName=## to set the async window size for a specific SMS User account with a user name of “AccountName”. (A window size of 0 specifies that async mode should be disabled for that account.)

This setting is only recommended for situations where it is necessary to improve the performance of delivering messages to an SMPP client.

For comments and further discussion, please click here to visit the NowSMS Technical Forums (Discussion Board)...