This is a fine idea - taking note of this for the next release. On Saturday, April 7, 2012 4:08:49 PM UTC+3, wim stevens wrote: > > Hello > > I have concerns about the processing of inbound multipart SMS messages. > Such messages have a few important fields: (below example taken from the > log) > > ConcatInformationElement[00, 03, 2D0202][MpRefNo: 45, MpMaxNo: 2, MpSeqNo: > 2] > > > In above example the multipart sms is identified by refno 45. The message > is composed of two parts. The current part is number 2. > > Smslib keeps in memory lists of these messages as they are coming in. > > private List<List<InboundMessage>> mpMsgList; > > > Smslib assumes the primary key is MpRefNo. > > The refno is a one byte value. So there are only 255 possible values. > More important: the refno is created in the mobile phone of the sender. > > Suppose two different GSM phones send multipart messages to a smslib based > server. There is a probability of 1/255 that they use the same MpRefNo > > Proposal: use the concatenation <phone number of sender><MpRefNo> as > primary key for storing the msMsgList > > Regards > > Wim Stevens > > > > > > >
-- You received this message because you are subscribed to the Google Groups "SMSLib Discussion Group" group. To view this discussion on the web visit https://groups.google.com/d/msg/smslib/-/UG7o_uHm8m4J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/smslib?hl=en.
