[standards-jig] JEP-0047 (IBB) Updated

Matt Tucker matt at jivesoftware.com
Mon Apr 7 20:21:41 UTC 2003


> Some people have gotten around this using JNI[3].

Unfortunately, that's not usually an acceptable workaround for any shipping Java app (although it could be for an internal app). As
I mentioned in my last email, all of this ends up making the client implementation a lot more complicated. Basically:

 1) Get a timestamp
 2) Make sure the timestamp isn't the same as the previous one sent out for a particular IBB UID (since as a Java app you don't know
if you're running on Linux, Windows, etc).
 3) If the timestamp is the same, try getting a new one from the system until it's different.

So, my workaround for all this pain would be to just start every IBB stream at 0 (1969 in Java) and then increment the value by one
for every new message. That makes the timestamp a virtual 64 bit counter in Java.

> 3)  This limit is with sending data, but not receiving.  In Java, the 
> Calendar and DateFormat classes allow for ms-level resolution (if not 
> smaller), plus the timestamp (for the receiver) becomes a unique tag, 
> that you can effectively do a String.compareTo() to determine 
> ordering.

Why not just use a counter and tighten up the rules on how the counter is used? This will allow much easier error detection of
missed packets, as was brought up in another email and avoids the whole mess of different time stamp implementations on different


More information about the Standards mailing list