twitter-archive / cloudhopper-smpp

Efficient, scalable, and flexible Java implementation of the Short Messaging Peer to Peer Protocol (SMPP)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

No length validation for PDU fields

skytreader opened this issue · comments

As the title says, I noticed that length is not validated for PDUs. They still get sent, leaving it for the other end to figure out that I overstepped the specified SMPP lengths. And then on my end, I've no idea that my field size is what went wrong.

[main] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - sync send PDU: (bind_transceiver: 0x00000037 0x00000009 0x00000000 0x00000001) (body: systemId [skytreader] password [morethanninecharacters] systemType [] interfaceVersion [0x34] addressRange (0x00 0x00 [])) (opts: )
[main] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - write bytes: [00000037000000090000000000000001736b7974726561646572006d6f72657468616e6e696e6563686172616374657273000034000000]
[jamsesh] INFO com.cloudhopper.smpp.impl.DefaultSmppSessionHandler - Default handling is to discard an unexpected channel closed

Note: As per SMPP3.4 specs, BIND password is only up to 9 chars.

(The scenario here is that I'm testing our Cloudhopper-based ESME app against a non-Cloudhopper-based local SMSC simulator. Thanks to that, I realized my blunder with the password length.)

Is there a reason why this is not included? This seems pretty simple I guess I can contribute if this is in anyone else's wishlist.

I honestly can't remember why we never validated lengths -- it was so long ago the decision was made. But if I had to guess -- it probably is that the SMPP specs are somewhat useless in the real world. For example, I vaguely remember an SMSC using longer than 9 chars (since the specs allow variable length fields terminated by a NULL char) and I was angered that I was checking the length to be a limit of 9.

If you think validation would be useful, I'd suggest making it A) optional and B) configurable with C) defaults per the specs.