Re: [RFC] unique SMS IDs

My two (oops! three) cents:

1. A GUID or UUID (Globally unique ID) can be generated. Libraries are available to generate such a unique ID depending on time or a random number on Linux.
Pros: Always guarantees unique ID irrespective of number of bearerboxes or message submission rate.
Con: Platform specific code.

2. Another ID generation can be similar to SMSC standards for generation of message IDs which is <timestamp>:<destination number>. 
Pros: Easy and platform independent.
Con: This is a subset of Stipe's Heuristical msg id generation. And also here most of the SMSC take timestamp to be of seconds granularity. Thus binding on gateways to send only one message per second towards a particular destination. So we can think of keeping a finer granularity approaching Millis. Also, under rare circumstance when multiple bearerboxes are running, it doesn't guarantee unique message ID across boxes. 

3. One of the solution can be to assign unique box id to each bearerbox running in the system and have message ID as <timestamp in  Millis>:<destination>:<box id>

comments?
Jeetendra.
  ----- Original Message ----- 
  From: Stipe Tolj 
  To: [email protected] 
  Sent: Friday, August 22, 2003 5:13 PM
  Subject: [RFC] unique SMS IDs


  Hi list,

  currently bearerbox acts like:
  whenever an SMS is passed to the store-file it get's an incrementaly
  counted ID and then stored.

  It is desirable (for several purposes) to have unique IDs for messages
  coming in (SM-MO), hence when entering the system from SMSC side and
  when leaving to the HTTP (application server) side, and of course vise
  versa.

  Hence, I'd like to discuss how we can acchive uniqueness of IDs
  accross even several parallel running bearerbox instances on one box.

  >From our perspective there are two ideas:

    * heuristical: assume that a constructed ID = timestamp + sender +
  receiver + counter is unique accross all instances.

    * ID pool caching: which means there is a thread in bearerbox with a
  ID queue. The queues in several concurrent bearerbox processes are
  distinct, which means the thread has to garantee whereever he obtains
  a pool of IDs, that those are assign only to himself. 

  Option 1 is of course simpler to do. Option 2 is *stronger* in the
  sense of high-load systems and consistancy.

  Any thoughs for this?

  BTW, I'd also like to add the SMS ID to the access.log. Any
  objecttions here?

  Stipe

  [email protected]
  -------------------------------------------------------------------
  Wapme Systems AG

  Vogelsanger Weg 80
  40470 Düsseldorf

  Tel: +49-211-74845-0
  Fax: +49-211-74845-299

  E-Mail: [email protected]
  Internet: http://www.wapme-systems.de
  -------------------------------------------------------------------
  wapme.net - wherever you are