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

Allowing unbound channel to respond to enquire_link PDU #101

Closed beastawakens closed 9 years ago

beastawakens commented 9 years ago

The SMPP spec does not seem to be clear in this regard but we have an instance of an ESME sending an enquire_link PDU and expecting a response while the channel is open but not bound. It seems that this could be valid according to section 2.4 (Operation Matrix) (http://docs.nimta.com/smppv50.pdf) as they can use this to check the channel is valid and available before making a bind request. Changing the behaviour of the UnboundSmppSession class to support this and send a simple response in reply.

jjlauer commented 9 years ago

Based on the matrix I agree it technically looks valid to allow an enquire_link in the "open" state (which this library calls an UnboundSession). On a practical level, its utility is marginal since sessions use TCP/IP and binds are expected to happen quickly after a connection is established. Connection really going to die in few ms after tcp/ip ack'ed the connection worked.

Regardless, I do agree they look like they are permitted. So, thx for the patch.

beastawakens commented 9 years ago

Thanks for the quick response Joe, much appreciated!

pgoergler commented 9 years ago

But it's not true for SMPP 3.4, In SMPP 3.4 EnquireLink request and response required a bound session. https://github.com/twitter/cloudhopper-smpp/blob/master/src/etc/SMPP_v3_4_Issue1_2.pdf (Section 2.3). so it will break the backward compatibility in protocol.

In SMPP 3.4, if the other side had a bug, restart and reuse the tcp link, or something that leads to mark your session as unbound, the enquire_link is the only way to know is the other side see you also as bound. If it doesn't reply => session in wrong state.

No?

jjlauer commented 9 years ago

Hey @edkellena -- @pgoergler raises an interesting point. SMPP v5.0 vs v3.4 are a bit different in the matrix. I had my reservations on allowing enquire links on unbound sessions -- which I do think is useless. I think your ESME is the first one I've heard trying to do it. While I think this is a minor issue, I suppose a badly implemented server could have an unbound session stay alive by sending enquire links (rather than timing out on lack of credentials). An alternative is to support both modes -- adding it as a feature to disable enquire_link checks on unbound sessions, but enforce it by default. What do you think?

beastawakens commented 9 years ago

Yeah, no problem with that, feature flag it to leave it up to the consuming application to decide on the behaviour it would like to enforce!

pgoergler commented 9 years ago

It seems the best way to implement both protocol.