May I also suggest to change this mpMsgList storage to: private Map<String<TreeSet<InboundMessage>> mpMsgMap
If the TreeSet is controlled by a comporator using mpMsgSeq and the Map is keyed by the suggested senderGSM-mpRefNo combination this would eliminate the dublicate check AND the double for-loop in the method handling multipart messages Best René Den lørdag den 7. april 2012 15.08.49 UTC+2 skrev wim stevens: > > 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/msgid/smslib/9e82c9e0-8ea6-43fc-99ef-e0c0fa559741%40googlegroups.com.
