Asynchronous Mode
Synchronous message submission
Chapter explains the idea behind and usage of the component in asynchronous mode.
There is a set of functions used to submit message to the SMSC. Functions like
SubmitMessage and
SubmitMessageEx work in synchronous mode. This basically mean that the function sends submit package to
the SMSC and waits for the answer. The communication diagram of the synchronous function looks like this:
After completion apart the result of the function call, returned is an unique value, often referred to as message ID. Later on as the component receives status reports, they are matched with messages submitted using the message ID received at the submission.
The time of submitting message in this paradigm is the time in which packet travels both ways plus time it takes the SMSC to process the message. Submitting subsequent message is not possible until previous submission sequence is finished. Great advantage of the synchronous submission functions usage is its simplicity. The performance can vary from few to few dozens of messages submitted per second depending on the bandwidth and delay introduced by the network connection.
Asynchronous message submission
The SMSC is almost always able to accept far more messages per second than can be send in synchronous mode. Asynchronous submission paradigm (also called sliding window) of subsequent messages looks like shown on the diagram below:
Message is submitted using SubmitMessageAsync function which returns immediately after sending it to the SMSC.
Information returned from the submit function is transaction number, which name varies among protocols. The transaction
number has to be stored by the application for some time. After a while the SMSC returns response to the submission and
the transaction number has to be used to match appropriate result with message submission. The result tells whether the
submission was successful and what is the message ID assigned to the message. From this moment everything goes identical
as in synchronous mode - the status reports can be matched via appropriate message ID.
The performance improves of course only if the application sends messages in a way where, as depicted above, the transactions overlap using more of the available connection bandwidth.
Performance gain
As can be seen above the performance gain between synchronous and asynchronous mode depends highly on bandwidth and delay introduced by the connection. In practical cases the messages can be submitted from 10 to 100 times faster. All this happens because all of the time can be consumed on submitting messages and there is no idle time on the connection.
Saturation of the SMSC
The real and often encountered limitation with asynchronous mode is that it is possible to saturate the SMSC. This happens when client goes above the pace at which the SMSC can accept message submissions. This usually causes the SMSC to start returning errors as the result of message submission. Depending on the protocol and the SMSC configuration these may be either critical or non critical errors. In the first case messages rejected may have to be retransmitted. In the second case client may react by limiting the number of messages submitted per time quantum. This action is called throttling and can be performed in a static manner by the component itself.