Handling ESME_RTHROTTLED: SMPP throttling, window size and backoff

2026-07-15 · smpp, performance

ESME_RTHROTTLED (0x00000058) means you are sending faster than your negotiated rate. It is not an error to swallow silently — it is a control signal. Handle it correctly and you keep throughput; handle it wrong and you either stall or get your bind dropped.

TPS is a contract, not a suggestion

Your carrier sold you a messages-per-second rate. Two things enforce it:

• Rate limiting — the SMSC rejects submits above the agreed TPS with ESME_RTHROTTLED.
• Window size — the number of submit_sm PDUs you may have outstanding (awaiting submit_sm_resp) at once. Exceed it and responses back up.

The backoff pattern

On ESME_RTHROTTLED, do not immediately retry the same message at full speed:

1. Pause new submits briefly (exponential backoff, e.g. 100ms → 200ms → 400ms).
2. Keep the window from refilling until responses drain.
3. Resume at a slightly reduced rate, then ramp back up.

Window tuning

A window that is too small under-uses your TPS (you idle waiting for responses on a high-latency link); too large and a slow SMSC buries you in throttles. Size the window to roughly TPS × round-trip-time, then measure.

Queue design

Put a rate-shaping queue in front of the bind so bursts from your application don’t translate into throttles at the SMSC. The queue — not the SMPP client — owns the pacing.