All: My software is available for download (in binary format for now), compiled from C# on Windows. (Will be ported to Mono later for Mac and Linux). It uses the depreciated 0.0.1 spec, sans feature negotiation, in case anyone wants to try XMPP Real Time Text in an experimential alpha manner.
http://www.realjabber.com/RealJabber_v0.0.1.zip > Imagine a satellite communications device (with > interval set to 2000ms ) connecting to someone else on a high > performance network (with interval set to 250ms). Then we now have an > interoperability problem. Even in tests, I ran into issues using > LAN-optimized intervals when running on a netbook running over an EDGE > data connection. This is amplified even further when using even worse > connections such as satellite or dial-up. I now think I need to expand on this paragraph about intervals. (Intervals of how often to send <rtt> elements) Interoperability problem caused by latencies can be caused by overwhelming the network traffic of bandwidth-limited devices like dial-up. XMPP Real Time Text can squeeze over dial-up, but can hit some limits especially if there's lots of other XMPP traffic (prescence stanzas on a big contact list, etc). Highly-shared satellite connections such as USA DirectPC and WildBlue go slower than dialup speeds, especially during peak periods. They have the addition of massive ping variability (fluctuations of over 1000ms) during peak periods. Cellular phone connections in poor reception areas (1 bar) can go slower than dialup speeds. Or when it's downloading things like a mobile email file attachment while you're chatting in another window (i.e. Android devices with multitasking). Even on my netbook test on a cellular connection, I was able to, from a remote XMPP client (set to very short 50ms and 100ms interval), overwhelm the netbook's chat application. So for maximized interoperability, software developers shouldn't have full freedom to choose just about any interval, and that is why we came up with a baseline recommendation of 1 second interval to cover the vast majority (albiet not all) of uses cases. It worked fine on all my use cases that didn't require latencies to be faster than 1 second. In my personal testing I actually preferred setting the interval to 300 or 500 milliseconds for desktop-to-desktop Internet communications. Related consideration: XMPP RTT is a potential channel of "Denial of Service" by flooding. But anybody can flood an XMPP server anyway, without needing the RTT spec. There was a lot of debate with the RealTimeText.org people about intervals. I feel that at the absolute minimum, a communicatable negotiable interval is absolutely necessary (the two clients connecting would simply choose the bigger of two intervals). Sincerely, Mark Rejhon
