Incomplete outbound multi-part message for some sizes

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Send a new message of size 386 bytes through library with 8-bit encoding
2. On the receiving end, only 378 bytes are received. 

What is the expected output? What do you see instead?

Complete 386 bytes are to be received on the destination modem or phone.

What version of the product are you using? On what operating system? In
case of Java, which Communication Libraries (JavaComm or RxTx) are you using?

RxTx 2.1.7-r2
smslib-java-v3.1-RC1.zip

Please provide any additional information below.

I use SMSLib for sending 8-bit encoded data to handsets. Most of the times,
the message is multi-part. When I send a message of size 386, only 3
messages are sent from the library, each one containing 126 bytes with 8
bytes of the message left behind and are not sent.

I stepped into the code and find out a discrepancy. In the method
OutboundMessage.getNoOfParts(), the total number of SMS that this big
message will create is calculated by dividing the size of the message over
132 (reserving 8 bytes for header). This amount to 3 SMS.

This calculation however would have been correct if 132 bytes are indeed
sent in each multi-part SMS. But with user data header, etc, only 126 bytes
are sent in each part, so there are 8-byte that are left behind.

I changed the code for the getNoOfParts() so that instead of dividing by
132, I started dividing by 126. This fixed the error and my few test cases
passed.

I have noticed that this problem may not occur for all message sizes, but
only for sizes where the multiplication values of 126 and 132 differ. e.g.
for message size from 379 to 396, the library will always send 3 messages
whereas actually 4 messages were required to be sent, because only 126
bytes of data is in each part.

Original issue reported on code.google.com by ak...@acm.org on 1 Dec 2007 at 6:38

[GoogleCodeExporter]

Can you please tell me if you are using Source / Destination ports in your 
message?

Original comment by T.Delenikas on 1 Dec 2007 at 8:50

• Changed state: Accepted
• Added labels: Platform-Java, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

No I am not using any source or destination port. Just plain destination MSISDN.

Original comment by ak...@acm.org on 1 Dec 2007 at 9:24

[GoogleCodeExporter]

Hi,

Please **replace** the getPart() method found in OutboundMessage with the 
following one:

String getPart(int partNo, int udhLength)
{
    int partSize;
    if (partNo != 0)
    {
        partSize = maxSize() - (udhLength / 2);
        partSize *= 2;
        if (((partSize * (partNo - 1)) + partSize) > getEncodedText().length()) return
getEncodedText().substring(partSize * (partNo - 1));
        else return getEncodedText().substring(partSize * (partNo - 1), (partSize * (partNo
- 1)) + partSize);
    }
    else return getEncodedText();
}

I've tested it with some examples (both 7 and 8 bit) and seem to work ok.
I would appreciate your feedback as well.

Thanks.

Original comment by T.Delenikas on 1 Dec 2007 at 9:16

[GoogleCodeExporter]

Hi,

I have replaced the code that you have provided in my file and the code now 
appears
to be working fine. The message size is still divided by 132 to get the total 
number
of SMS that the big message will create. And since now the getParts() subtract 
the
udhLength/2, which in my case comes out to be 133, so the getParts() will 
always be a
bit higher than than total parts, which will fix the things.

I have tested it with my cases, and so far it works. I will test it a bit more 
with
some other cases, and will let you know if something pops up. Thank you for the
prompt response.

Thanks,
Akbar.

Original comment by ak...@acm.org on 4 Dec 2007 at 5:16

[GoogleCodeExporter]

Thanks for the confirmation, Akbar.
Feel free to reopen the issue if you find any more problems.

Fix scheduled for RC2.

Original comment by ad...@smslib.org on 4 Dec 2007 at 6:50

• Changed state: Completed

[GoogleCodeExporter]

Original comment by T.Delenikas on 5 Dec 2007 at 7:50

• Changed state: Fixed