This repository has been archived by the owner on Sep 18, 2021. It is now read-only.
fix (and test) for encoding submit_sm_resp messages with no message_id #31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Working with a provider who leaves off the message_id in error submit_sm_resp, I noticed that the PDUEncoder was throwing a ArrayIndexOutOfBounds exception when trying to append a \0 byte to the buffer.
Digging deeper, it seems this is actually acceptable behavior according to SMPP 3.4 (but not 3.3 or 5.0):
http://en.wikipedia.org/wiki/Short_Message_Peer-to-Peer#submit_sm_resp_incompatibility_between_SMPP_versions
It seems like some places in the code already account for this ambiguity, but the PDUEncoder did not.
There is one edge case this fix does not cover, but I do not think it is important. Consider a submit_sm_resp with a non-0 status, an omitted message_id, and the existence of optional parameters. In this situation, I maintain that it's not always possible to disambiguate between when the message_id null-terminated-string ends and when the optional parameters begin; it seems like an oversight of the 3.4 spec.