# What is SMPP window size?

> The window is the number of SMPP PDUs an ESME may have in flight — submitted but not yet acknowledged — on a single bind at any moment. It is the single biggest determinant of the throughput you get from a bind, and the setting most often left at a default that silently caps an integration far below its agreed rate.

- Canonical URL: https://www.broadnet.me/answers/what-is-smpp-window-size
- Language: en
- Last reviewed: 2026-09-10
- Publisher: BroadNet (https://www.broadnet.me)

## Why a window exists at all

SMPP is asynchronous: you send a submit_sm and the SMSC replies with a submit_sm_resp, but you do not have to wait for that reply before sending the next PDU. The window is how many you are allowed to run ahead. With a window of 1 the session becomes request-response, and your throughput collapses to one message per round trip — on a 50ms link that is 20 messages a second regardless of what your contract says.

## The arithmetic

Rough throughput is window size divided by round-trip latency. A window of 10 against a 50ms round trip gives roughly 200 messages per second on one bind; a window of 50 gives around 1,000. This is why two customers on identical commercial terms can see wildly different real throughput — one has tuned the window and the other has not. Raising the window costs nothing on your side except memory for the unacknowledged PDUs.

## Why you cannot just set it to 1,000

The window is agreed with the operator or provider, and exceeding it gets you ESME_RTHROTTLED responses or a dropped bind. The SMSC has to hold state for every unacknowledged PDU too. Beyond a certain point the bottleneck moves from the window to the SMSC's own submission rate, and a larger window only deepens a queue you cannot drain. Agree the window and the TPS ceiling together, and treat them as one setting.

## Multiple binds and ordering

When one bind is not enough, the answer is more binds rather than an unbounded window — most providers allocate throughput per bind. Be careful with message ordering: PDUs across separate binds have no guaranteed relative order, so a multi-part message or a sequence a user will read in order should stay on one bind. Keep an enquire_link running on each so an idle bind is not silently dropped.

## Related

- [All answers](https://www.broadnet.me/answers)
- [Glossary](https://www.broadnet.me/answers)
- [What is SMPP?](https://www.broadnet.me/answers/what-is-smpp)
- [What is an ESME?](https://www.broadnet.me/answers/what-is-esme)
- [What is TPS (Transactions Per Second)?](https://www.broadnet.me/answers/what-is-tps)
- [How do I scale SMS throughput?](https://www.broadnet.me/answers/how-to-scale-sms-throughput)
- [SMPP](https://www.broadnet.me/developers/smpp)
- [SMSC Gateway](https://www.broadnet.me/operators/smsc-gateway)