On Wed, Jun 27, 2012 at 4:12 AM, Kevin Smith <[email protected]> wrote:
> On Wed, Jun 27, 2012 at 8:46 AM, Mark Rejhon <[email protected]> wrote: > > 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! > > We're at risk of veering violently off-course here, but ... > When using stream resumption on that sort of time scale there doesn't > need to be any catch-up performed by the sender, as the recipient will > receive all of the individual edits that the sender transmitted during > the outage when they resume the session. > Yes, that's a valid scenario. It often works fine. (especially with Google servers, which seems to have generous flood settings) However, if you enable the full rich spectrum (i.e. key press interval encoding) you can have 100 kilobytes of <rtt/> stanzas queued up during a network stall. I've seen servers 'treat' it as a flood when it all surges through. People do sometimes spend 5 minutes typing a long message, and a network stall of 3-4 minutes in the middle of that message, will queue up an awful amount -- over 100 kilobytes of <rtt/> over that 3-4 minute period. Also, flow control can potentially be used (i.e. message acknowledgements), allowing you to decide to stop transmitting RTT if the last few RTT goes un-acknowledged, and resuming transmitting RTT (with the first resumed RTT being a message reset). Far more bandwidth efficient in transient environments such as mobile. Picture the weak cell phone reception. Precisely the situation where bandwidth is congested/narrowband due to weak reception. Precisely the moment we least want <rtt> congestion from queued <rtt> not yet delivered. Reception loss is 15 seconds, 30 seconds, 5 minutes, 10 minutes, 30 minutes? Where do we draw the line in queueing up the <rtt>? We go into murky waters here -- congestion is unbounded here! There is no defined limit to number of <rtt> possible in one single message: You can type, backspace, type, backspace, and spend all day doing that. Message-reset events resolve this issue quite conveniently, and limits the bounds of the amount of data needed. Message reset events are extremely simple. Side distraction: I just noticed -- in theory, real-time text can be run entirely only using message-reset events (retransmitting the whole message every second). This is actually not too inefficient if you're limiting yourself to SMS-sized messages (160 characters or less) and need a very barebones implementation of XEP-0301. So, apparently, recipients don't need to support outgoing transmission action elements other than <t>, if they're only doing message resets as the method of real-time text. It would be bursty-output though, with no key press intervals, though. A suggested limit of ~1000 characters seems reasonable to add to this > as well (Which roughly ties in with your suggestion of a 2048byte > limit in your UTF-16 text box, I think). > I used to have a number there a year ago. I was told it's not a good idea to define an arbitrary limit, so I don't think I should mention a specific value, except general wording that it should be sufficiently small enough to avoid becoming a congestion consideration. The question is what wording to choose...
