does not wrap the reference_number when it reaches
64K.
A more teoretical problems with the segmentation code are.
If the session restarted the reference_number is reset,
or when the reference_number wraps, there is a risk
of reusing the same reference_number to the same
destination before the previous messages with the
same reference number have been delivered to the MSE.
If several sessions are used to send to the same SMSC the
same problem could happen. (Not sure if that is allowed.)
/Anders Nygren
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are absolutely right. The reference_number needs to be wrapped. Thanks a lot ;-) we were about to put this in production.
As I understand, the reference_number is in the session scope. If the session is restarted (dropped and another one created), then you are in a different session, thus, restarting the counter seems OK. The same applies if we have two different sessions with the same SMSC, each one has its own reference_number. I don't see a problem there.
Version 1.2 is coming soon with some neat changes. Hope you like them.
Quique
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Yes, that makes sense, the reference number should be session specific.
I am still a little worried about using the same reference number on different messages to the same destination
after the counter has wrapped.
I am working on a project where we will send several million
messages during the night for delivery during the day, using
scheduled_delivery. So the counter will wrap 50-100 times
per day.
But I will wait and see if it is a real problem before I start
making things more complicated than they have to be.
/Anders
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Another thing I noticed in the CVS version is that it is always using ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE.
Depending on the data_coding, 7-bit or 8-bit, the values of ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE are not the same.
Since It is possible to use different data_coding in different messages it is necessary to use different values for ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE depending on the data_coding.
Using the smallest values for ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE leads to sending more messages than are really necessary, which increases the costs.
/Anders
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Having them as configuration parameters are not enough.
Since it is possible to send messages with different data_coding on the same session, for example, some messages with 7-bit text and some with 8-bit binary data.
So ideally the segmentation code would check the data_coding parameter in the SMPP PDU and depending on if it is a 7 or 8 bit use the correct SM_MAX_SIZE and SEGMENT_MAX_SIZE.
This only becomes a problem with messages longer than ~1K, and I dont think it will be a problem for me this year.
/Anders
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Quique wrote:
>As I understand, the reference_number is in the session
>scope. If the session is restarted (dropped and another one
>created), then you are in a different session, thus, restarting
>the counter seems OK. The same applies if we have two
>different sessions with the same SMSC, each one has its
>own reference_number. I don't see a problem there.
Apparently the reference number relates to {SourceAddr,DestAddr} so it is necessary to remember the reference numbers used between sessions, and if several sessions are used for sending messages with the same SourceAddress they must be aware of each other so they dont use the same reference number for messages to the same DestAddr.
/Anders
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I am looking at the new version in CVS and there is a bug
in the handling of messages longer than 160 bytes when
using segmentation.
The msg_ref_num is defined to be 2 bytes but
gen_esme_session:handle_sync_event(reference_number, _From, SName, SData)
does not wrap the reference_number when it reaches
64K.
A more teoretical problems with the segmentation code are.
If the session restarted the reference_number is reset,
or when the reference_number wraps, there is a risk
of reusing the same reference_number to the same
destination before the previous messages with the
same reference number have been delivered to the MSE.
If several sessions are used to send to the same SMSC the
same problem could happen. (Not sure if that is allowed.)
/Anders Nygren
You are absolutely right. The reference_number needs to be wrapped. Thanks a lot ;-) we were about to put this in production.
As I understand, the reference_number is in the session scope. If the session is restarted (dropped and another one created), then you are in a different session, thus, restarting the counter seems OK. The same applies if we have two different sessions with the same SMSC, each one has its own reference_number. I don't see a problem there.
Version 1.2 is coming soon with some neat changes. Hope you like them.
Quique
Hi
Yes, that makes sense, the reference number should be session specific.
I am still a little worried about using the same reference number on different messages to the same destination
after the counter has wrapped.
I am working on a project where we will send several million
messages during the night for delivery during the day, using
scheduled_delivery. So the counter will wrap 50-100 times
per day.
But I will wait and see if it is a real problem before I start
making things more complicated than they have to be.
/Anders
Hi
Another thing I noticed in the CVS version is that it is always using ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE.
Depending on the data_coding, 7-bit or 8-bit, the values of ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE are not the same.
Since It is possible to use different data_coding in different messages it is necessary to use different values for ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE depending on the data_coding.
Using the smallest values for ?SM_MAX_SIZE and ?SEGMENT_MAX_SIZE leads to sending more messages than are really necessary, which increases the costs.
/Anders
I see. I'll be better to set them as setup values. Thanks for your feedback.
Hi
Having them as configuration parameters are not enough.
Since it is possible to send messages with different data_coding on the same session, for example, some messages with 7-bit text and some with 8-bit binary data.
So ideally the segmentation code would check the data_coding parameter in the SMPP PDU and depending on if it is a 7 or 8 bit use the correct SM_MAX_SIZE and SEGMENT_MAX_SIZE.
This only becomes a problem with messages longer than ~1K, and I dont think it will be a problem for me this year.
/Anders
Hi
Quique wrote:
>As I understand, the reference_number is in the session
>scope. If the session is restarted (dropped and another one
>created), then you are in a different session, thus, restarting
>the counter seems OK. The same applies if we have two
>different sessions with the same SMSC, each one has its
>own reference_number. I don't see a problem there.
Unfortunately this is not correct, see http://smsforum.net/smf/index.php?PHPSESSID=f3fefd2e6d301ad5afc9823696b38cb3&topic=2009.0
Apparently the reference number relates to {SourceAddr,DestAddr} so it is necessary to remember the reference numbers used between sessions, and if several sessions are used for sending messages with the same SourceAddress they must be aware of each other so they dont use the same reference number for messages to the same DestAddr.
/Anders