Reliable SMPP sessions: bind, enquire_link, reconnect and windowing

An SMPP connection is not reliable merely because its TCP socket is open. A production integration must track bind state, enquire_link exchange, the response deadline of every PDU, the in-flight request window and recovery after a disconnect. Otherwise a short network interruption can become a stuck queue, duplicate SMS messages or a broken relationship between submission and its DLR.

Model the connection as states

A finite-state machine makes failure handling explicit:

1. DISCONNECTED — no connection; submission is paused;
2. CONNECTING — TCP or TLS is being established;
3. BINDING — the bind request has been sent;
4. BOUND — the session may carry application traffic;
5. DRAINING — no new work is accepted while in-flight requests finish;
6. UNBINDING — an orderly shutdown is in progress.

The client enters BOUND only after a successful bind_resp. A completed TCP handshake does not prove that the credentials were accepted or that the SMSC will process submit_sm.

bind_transceiver is commonly used for bidirectional traffic. Separate transmitter and receiver sessions may be appropriate when required by the provider or platform architecture. Agree the bind mode, connection count and limits with the provider: opening extra sessions without coordination may trigger throttling or blocking.

A heartbeat tests more than the network

enquire_link detects a connection that appears open but no longer exchanges PDUs. Its interval should be shorter than the idle timeout of every intermediary, including load balancers, NAT and firewalls, without creating unnecessary control traffic.

Use three independent timers:

• idle time before sending enquire_link;
• the deadline for enquire_link_resp;
• the response deadline for an application request such as submit_sm_resp.

When the deadline expires, treat the connection as indeterminate, close it and establish a fresh session. Waiting forever on an old socket is more dangerous than a controlled reconnect.

Reconnect without a thundering herd

After an outage, many client instances may reconnect at once. Exponential backoff with jitter spreads this load—for example 1, 2, 4 and 8 seconds, capped at an agreed maximum and modified by a random component.

Different failures need different policies:

• network interruption — retry after backoff;
• temporary bind failure — make a limited number of attempts and alert operations;
• invalid credentials or forbidden bind mode — stop automatic retries;
• planned shutdown — drain, then unbind cleanly.

Reset the attempt counter only after a stable operating period, not immediately after TCP connect. Otherwise a session that repeatedly fails just after bind can retry without restraint.

Request windows and sequence numbers

SMPP allows several unacknowledged requests in one session. The window size controls how many submit_sm PDUs may be in flight. A window of one is simple but limits throughput to the response latency. An oversized window increases speed, yet also increases the number of indeterminate operations during a disconnect.

For every request, persist or track:

• sequence_number;
• the internal message identifier;
• submission time and response deadline;
• the session generation;
• submit_sm_resp status and returned message_id.

Do not correlate an old response with a new session by sequence number alone. The number has a finite range and is reused, so the session context must be part of the correlation key.

Choose the window through load testing alongside SMS TPS and queue planning. The objective is stable latency without rising timeouts or throttling, not the largest possible PDU rate.

Handle indeterminate submissions deliberately

The hardest case occurs when submit_sm left the client but submit_sm_resp was lost during a disconnect. The application cannot know whether the SMSC accepted the message. An unconditional retry may create a duplicate; abandoning it may omit the notification.

The business policy should depend on the message class:

• for OTP, issuing a fresh code and invalidating the old one is safer than blindly repeating the same text;
• for service notifications, use an event key and a bounded deduplication window;
• for marketing traffic, retrying an indeterminate submission is usually less justified;
• for critical events, reconcile against the platform journal or an agreed API when available.

SMPP does not provide end-to-end exactly-once delivery. Duplicate control belongs in the application, queue and integration layer. The transactional outbox pattern for SMS explains how to persist a business event and its submission task atomically.

DLRs outlive the session

A delivery receipt may arrive on another session and long after submit_sm_resp. Correlation must therefore survive a process restart. After a successful response, store the platform identifier, message_id, recipient, route and submission time.

Normalise the identifier and status model for the specific provider. submit_sm_resp acknowledges platform acceptance, not handset delivery. The distinction is covered in more detail in SMS delivery metrics and DLRs.

Operational metrics

At minimum, observe:

• current state and age of every session;
• bind and reconnect counts with failure reasons;
• P50/P95/P99 submit_sm_resp latency;
• request-window utilisation and expired requests;
• throttling and permanent error rates;
• queue age and depth by message class;
• indeterminate submission and retry rates;
• DLR delay and completeness.

An alert for “socket disconnected” alone is insufficient. A connection can remain established while its window is full of expired requests and application delivery has stopped.

Failure-test checklist

Before production, test:

1. disconnects before and after submit_sm;
2. missing submit_sm_resp and enquire_link_resp;
3. slow responses without a full disconnect;
4. rejected binds and credential changes;
5. throttling at the contracted TPS;
6. active-session handover between client instances;
7. sequence-number reuse after restart;
8. DLR arrival after reconnect and process restart;
9. orderly drain during a deployment;
10. queue recovery without a duplicate burst.

Practical conclusion

A reliable SMPP integration combines an explicit state machine, a bounded request window, independent timeouts, jittered backoff and durable message correlation. Do not copy universal interval values: match them to the route contract and verify them under realistic load.

Before connecting to QuickTel, document the bind mode, session count, TPS, window, heartbeat, retry rules and DLR format. This contract gives the application, platform and operations teams the same interpretation of failures.