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

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Mon Apr 7 19:08:23 UTC 2003

Personally, I don't see this as a real problem.  Here's why:

1)  The resolution of timers in Java is dependent upon the underlying 
platform and JRE implementation[1].  Linux JREs enjoy 1 ms resolution, 
while 10 ms is the limitation on Windows NT/2000/XP, and even 50 ms on 
Windows 9x[2]. Some people have gotten around this using JNI[3].

2)  Timestamps (if thought out) will "transparently" support faster 
systems.  If you cap the throughput based on the timer resolution of the 
system, faster systems would have higher throughput (becaause they would 
have a shorter interval between timer updates), and you won't have to 
rewrite your code.

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.

-  LW
[2] http://www.javaworld.com/javaqa/2003-01/01-qa-0110-timing_p.html

Matt Tucker wrote:
> Temas,
>>So how do we solve the seq mess?  The solution that myself 
>>and a few others have been suggesting is that packets are not 
>>sent with a sequence number, but rather a high resolution 
>>(millisecond) timestamp of when the packet was transmitted.
> As someone from the Java world, I'll have to argue against this particular suggestion. The highest time resolution that most Java
> implementations can achieve is somewhere around 10 ms. That's not nearly accurate enough for what you're proposing. It also puts an
> additional onus on client developers since they'd need to add code to ensure that the date values are always different for every
> packet. If I had to implement the JEP under Java using timestamps, I'd probably just pick an arbitrary date, then add 1 millesecond
> to every packet I send. Essentially, this would just be an unbounded counter so I don't see how it provides much of an advantage
> over the current JEP (as long as the current JEP packet ID's were cleaned up as you suggest).
>>The error state 
>>really needs a lot of flushing out still, such as what to do 
>>when an error is encountered in the middle of a transmission 
>>by the sender (bounced packet).
> Right, it would be a bummer if the entire stream was corrupted due to a single lost message. 
> Regards,
> Matt
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)

More information about the Standards mailing list