Sniffing Out SMPP Responses

Setting up SMPP to handle your messaging is all good and well, but what now? The key to efficient messaging lies in analysing PDU (Protocol Data Unit) packet content.

You’ll note that we’re going a little green lately, environmentally green, that is. This not only relates to using SMS to engage your contacts instead of getting your jobless mate to hand out flyers on busy street corners (flyers come from trees, dontcherknow?), it also relates to efficient computing by ensuring your machine only works as hard as it needs to. After all, studies suggest that the average PC wastes about 50% of its power, to but it bluntly. And when PCs work hard, they use more power. Efficient SMPP, or messaging for that matter, is the answer. And here’s how…

A Bit of SMPP Background…

SMPP, or Short Message Peer-to-Peer, is a protocol. This fact in itself means quite a lot since you’ll be able to integrate SMPP into just about any software environment possible. It’s a versatile little protocol, and sends back a response for every PDU delivered to the SMS gateway. Said PDU’s can either be sent synchronously (which basically means the next packet won’t be delivered until a response is received for the first one) or asynchronously (which means your machine will send X amount of packets in quick succession, and receive their responses in the same manner.

Efficient SMPP-ing

Now, before we continue I’d like to point you to the SMPP Specification Guide 2.4.3 in which you’ll be able to find the supported PDU’s and much, much more. Although SMPP v5.0 has been released, the most popular version in use today is still v3.3. One slight difference with Clickatell’s SMPP version is that the BIND_TRANSCEIVER field has been enabled, which means you only need one virtual connection to accomplish two-way SMS messaging (as opposed to traditional v3.3 which requires you to have one SMPP connection running for sending and receiving respectively).

That being said, how do you sniff out SMPP response packets?

With a packet analyser, of course. For those who don’t know what that is, here’s Wikipedia’s definition:

“A packet analyzer (also known as a network analyzer, protocol analyzer or sniffer, or for particular types of networks, an Ethernet sniffer or wireless sniffer) is computer software or computer hardware that can intercept and log traffic passing over a digital network or part of a network. As data streams flow across the network, the sniffer captures each packet and, if needed, decodes and analyzes its content according to the appropriate RFC or other specifications.”

Pretty simple. Well, almost. The thing is that if you use a sniffer on your network, even just on your local subnet, you’ll probably receive a lot of garbage, and I do mean a lot. As such you’ll have to tell your sniffer on which ports to listen for traffic, e.g. 2345 or 2346.

Once you have your sniffer set up correctly, the output can then be saved to file. Use this file to check for PDU’s that returned error messages. These errors can then be corrected and enable you to do even more efficient computing, thereby conserving energy, and thereby looking after the environment.

P.S. Always check with your system or network administrator first before using a packet sniffer. It is essential that you have permission and that it is generally known what you are using the packet sniffer for (as with the Force, packet sniffers can also be used for evil).

Need more information on this wonderful protocol? Simply make your way to our SMPP page.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Tags: asynchronous SMPP, packet analyzer, Short Message Peer-to-Peer protocol, SMPP, SMPP response packets, SMPP specification, synchronous SMPP