search

twitter-archive / cloudhopper-smpp

Efficient, scalable, and flexible Java implementation of the Short Messaging Peer to Peer Protocol (SMPP)
Other
381 stars 357 forks source link

Session will be (automatically) destroyed when ShortMessageLength in SubmitSm PDU is too small #64

Open kbeholz opened 10 years ago

kbeholz commented 10 years ago

Hi, recently we noticed the following case:

We received a SubmitSm PDU where everything was ok BUT the ShortMessageLength was set too small (while the command length was ok). That caused that the Session was destroyed immediately.

We would have assumed that the Server might throw an Exception like an UnrecoverablePduException or a RecoverablePduException or anything like that so that we were at least able to send a response (rejection) to the message.

We are still running on the following version: 5.0.0 (2012-10-26). As I did not find any matching issue here we assume that this issue is still present in the current version. Could anyone please confirm this?

Example PDU for testing: 00000070000000040000000000000008000501414243444546000101303132333435363738393132000000000000010000003c6b61746265686f6c7a20667269656e646c792074657374206d65737361676520323a204772656574696e67732066726f6d205669656e6e61203a2d2900 (Command Length is 112 bytes, ShortMessageLength is set to 60 bytes while it is actually 61 bytes long due to the 0-byte at the end)

If anyone has an idea to handle this issue without changing the code base of the Cloudhopper, please let me know. Maybe there is any RuntimeException we did not notice so far but could catch in "our part" of the code.

Thanks in advance for your help.

jjlauer commented 9 years ago

Just wondering what you ended up doing? The library attempts to recover from bad data -- although it may think in this case that the session is hosed -- e.g. reading any further data from the socket would be dangerous. Was a real SMSC sending this?

kbeholz commented 9 years ago

Actually we did not change anything in the Server so far to handle such PDUs in a better way. Seems like it did not happen again after we contacted our customer who was sending those PDUs and told them about the failure.