On Wed, Jun 27, 2012 at 3:12 AM, Kevin Smith <[email protected]> wrote:
> Given reliable underlying streams (i.e. XEP-0198 between the servers) > you should, in all of these cases, receive either an unavailable > presence from the recipient or receive message bounces if an RTT > element is missed. > Even with XEP-0198, and even with good stream resumption, the sender may have spent 30 seconds typing 200 keypresses during an unavoidable network stall (i.e. lost WiFi / 3G mobile phone reception). Even with perfectly bug-free stream management, you still have to do a message catch-up of some kind! Thus, some variant of section 4.6.4 is still relevant -- It's more efficient to catch up the real time message by sending one <rtt/> when the sending client decides it's safe to resume sending <rtt/>. You still have to sync the currently-being-composed message on sender/recipient sides, preferably in one stanza containing <rtt event='reset'/> stanza. Perhaps this should be called "real time message catchup event" rather than a "retransmission"? I chose "retransmission" terminology because it was a simple catch-all word? What about calling them "Message Resets" instead of "Retransmission"? Is there better terminology? > Retransmission seems entirely appropriate when an entity that > previously didn't support RTT (e.g. because it was offline) starts to > support RTT - but frequent retransmission because some entity along > the path has failed seems wrong to me. > Again, I now think it's a terminology issue. The word "retransmission" may be wrong. > With that said: If retransmission only occurs during transmission of a > stanza that would otherwise have already been sent containing an edit, > this is probably not going to have a significant detrimental effect on > most networks (although I'm aware of some networks where RTT sounds > like a good idea but the extra bandwidth could tip it over the edge), > except in the case of these hypothetical 64k and upwards copy/paste > messages (and I suspect the XEP should suggest that RTT be disabled > for copy/paste messages), which horrify me. I have a better suggestion: I should find a place in the document, perhaps in "Congestion Considerations": *"The sender's message entry ideally needs to have a reasonable maximum length limit, to allow real time text to be always available without the congestion concerns of large message stanzas, such as those during abuse of large copy-and-pastes." * I've seen lots of XMPP chat software don't put a size limit on their message-entry text box, and it's possible to paste a large enough message that fails message delivery. Not good for XEP-0301. Software that supports XEP-0301 should keep the text box to a reasonable size. I use a 2 kilobyte limit in a text box, in one of my clients, to eliminate this concern. The maximum abuse possible caused by infinitely fast copy and pastes, assuming the spec and transmission intervals are followed, is 2 kilobytes + overhead per message transmission cycle. It would then just 'look like' an in-band file transfer running slightly above ~2Kbytes/second. So the 'damage' is limited by putting a length limit on the "Send" textbox. Smart recipients can also internally further rate-limit copy and pastes (temporarily pause RTT), but the RTT message still eventually needs to be synced between sender/recipient ends, so that would mean as soon as copy and pastes stop, a message reset simply eventually occurs, which copies only the last copy and paste, ignoring transmission of earlier copy-pastes during copy-paste abuse.
