> Mark Rejhon skrev 2011-08-18 05:33: >> >> XEP-0301 has section 10.2 >> that suggests you can dynamically lengthen the transmission interval >> in order to survive extreme conditions like those you described. (i.e. >> 2,000 or 3,000ms). Please note that this is no longer really >> "REAL-time text" (it's only near-real time). > > <GH>I agree with Mark's conclusion. Automatic disabling of the real-time > text feature and falling back to message mode will confuse users who are > used to not needing any special action for their text to be sent.
Yes, Gunnar makes a good point -- automatic mode changes are undesirable. One might view automatic changes of interval as a small mode change, too. Generally, in order of preference, for user-experience, it is: (1) Real time text smoothed presentation (natural typing or time-smoothed, 1000ms interval or less) (2) Short-latency real time text bursty presentation (near-fluid 300ms bursts) (3) Longer-latency "near real time" text smoothed presentation (natural typing or time-smoothed) (4) Longer-latency "near real time" text bursted presentation (uncomfortable bursts) (5) Message-by-Message mode (if this must be done, display a very clear indicator) The only situation I can see where it's necessary to make a "major mode change" when we're bandwidth-starved on dial-up-league links. However, this situation is so rare, it's not normally necessary to complicate programming in order to do this. My sample open source code at www.realjabber.org doesn't do this. It's just that XEP-0301 allows this flexibility, for a mission-critical application. One possible simpler congestion-recovery algorithm that complies with section 10.2 of XEP-0301 is simply using the average latency of the last several message delivery receipts (XEP-0184) to automatically set the interval, if it's longer than the default 1000ms. This would "automatically" survive the vast majority of congestion scenarios, including overloaded XMPP networks, as well as GRPS at 3000ms. Or if message delivery receipts is too frequent (one would be sent back every second), then using XMPP ping at regular intervals (say, once every X seconds, or once every X RTT packets), and using that for latency calculations to set the RTT latency. That way, when congestion dissapears, the latency is under 1000ms, and XEP-0301 is "back to normal" (default transmission interval) .... And by following section 10.2, the software become automatically "nice" to the XMPP network because we slow down our message deliveries if the XMPP network gets overloaded (network latencies go up). And, also, if using XEP-0184 message delivery confirmations, lost RTT transmissions can be detected and trigger retransmission (see section 4.6.4 of XEP-0301) in an advanced implementation of XEP-0301. Mark Rejhon
