[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. Linux JREs enjoy 1 ms resolution,
while 10 ms is the limitation on Windows NT/2000/XP, and even 50 ms on
Windows 9x. Some people have gotten around this using JNI.
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.
Matt Tucker wrote:
>>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.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
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