Am 08.03.2012 00:29, schrieb Mark Rejhon: > On Wed, Mar 7, 2012 at 1:15 PM, Florian Zeitz <[email protected]>wrote: > >>> The seq was developed, because, it was found in fact to be necessary. >> [snip] > >> One of my main points here was that I don't see the use specifically for >> reconnects. Upon reconnect it is clearly the sender's responsibility to >> start a new session with the receiver. After all the receiver might have >> lost all state at that point. > > Actually, in real practice, disconnects and reconnects are seamless in a > lot of software. For example, many mobile chat programs are designed to > automatically reconnect (even while in the middle of composing a long > instant message) when reception comes back & the original XMPP session > timed out due to lack of reception. > > It is very simple, and very "in-line" with the way of prevailing use cases > that are common in certain brands of wireless mobile chat applications > (iPhone, Android). Although not all of them do things this way, many of > them do the following, for disconnect-reconnect: > > SITUATION: Automatic disconnect-reconnect cycle done in background > EXAMPLE: Cellphone loses reception. Server times out the connection. > Spontaneous disconnect. User still has a partially composed message > that's not yet sent. > WHAT HAPPENS: Chat window stays open. Send button becomes disabled. > Partially composed message is not erased (he can copy and paste it > somewhere else or reconnect) In polite software design, the chat window is > still visible so that the user can still view chat history even though the > user lost connection. Often, the user will have a partially-composed > message when the chat software suddenly disconnected. (You're on a train > that just moved through a tunnel, and the reception suddenly got lost. > You've suddenly walked into an elevator, etc) Suddenly, the chat client > reconnects in the background, and the chat window becomes "live" again. > The user now has an opportunity to send the partially-composed message. > Thank you. Believe it or notm I have in fact used an instant messenger before. I however fail to see how this is relevant to any of this. The point is that such a "seamless" reconnect (from the receivers UI point of view) is (for the sender) indistinguishable from, let's say, my device crashing and me signing in with the same resource from a completely different device almost immediately after.
>> I think it would be way more sensible to >> specify that the first RTT message sent to a resource that was >> previously offline needs to have event="new" or event="reset". >> For stanzas getting lost on life streams sequence numbers appear like a >> sane solution though. >> > > I actually already specify this -- I already mention this as part of the > "Error Recovery" -- that a client SHOULD do an event="new" or event="reset" > if the user comes back online. It is not currently a MUST because if the > client doesn't do it, it is not fatal to interoperability of real-time text > -- it just means real-time text automatically resumes a little bit later. > (Using fewer "MUST"s is beneficial to a specification) > I can only assume you're talking about your working copy, because there is not a single SHOULD requirement in that section in the published version of XEP-0301. I do also believe this is entirely the wrong place for such a statement. The matter of fact is simply that a newly only resource (no matter whether it reconnected, or connected for the first time) SHOULD be sent an <rtt/> containing either event="new" or event="reset" as the first RTT message. Doing anything else is bound to imply sending data to the receiver that it can not possibly understand. I do however agree that the way XEP-301 works this is in fact a SHOULD requirement, as failure to comply with this is not fatal. > Note that retransmissions are OPTIONAL. (the planned addendum to XEP-0301) > Note that no retransmissions occur when no typing is done. (so we don't > lose bandwidth during idle moments) > Disclaimer: With one of my clients, I have done work to help implement > XEP-0301 in a Next Generation 9-1-1 experimental demo, and this > retransmission is actually added because of this paid-work experience. > Work for NG9-1-1 is currently one of my sources of income for XEP-0301. > Ack. "OPTIONAL" seems like an appropriate requirement level. >> Which reminds me of something I forgot to mention in my last message. >> Unless I overlooked it there is no defined behaviour once 'seq' is >> incremented past 2^32-1. Assuming wrap around, it would be nice to have >> a note that implementations need to make sure to not accidentally assume >> desynchronization when this happens. >> > > You're right -- I knew I should have added a note -- but then I then > realized it would take more about 50,000 years for this to happen, and the > desynchronization would only be very temporary (it would only last until > the next event='new' or event='reset'). Since seq increments once per > second during continuous typing, it would take 50,000 years of continuous > typing at a default transmission interval, for the wraparound scenario to > happen. And if it even did wraparound, the penalty is only a stall of a > few seconds caused by not defining wraparound behaviour. Also, some > programming languages (i.e. Java) do not have unsigned integers (only > signed integers), which compliates trying to a note about an event that > would never happen in normal practice. Would you like to suggest an idea > of a single-sentence note that can be added? > If you're going to (as you said earlier) drop the requirement of starting at "0" this becomes more of a problem. Clients could implement TCP-ish behaviour of starting at a random sequence number. The upper limit would then potentially be hit sooner. Somewhat inspired by the text in RFC 793 I'd suggest: "Arithmetic on the sequence number MUST be be performed modulo 2**32. In particular the sequence number wraps around to 0 when incremented past (2**32 - 1). Note that comparison of sequence numbers has to accommodate for this fact." >> However, I've found enough reason to keep both <d> and <e> -- but our team >>> can still be swayed by further arguments against having both. >>> >> I like that approach. Always having cursor repositioning implicit in the >> edit actions seems compelling to me. At that point having both <d/> and >> <e/> would not seem as icky to me either. As I understand it the main >> change here would be that <d/> and <e/> are redefined to perform >> absolute repositioning of the cursor instead of performing a relative >> movement of 0 and -1 respectively. This also addresses my other concern >> about the possibility of positioning the cursor outside of the text. > > > Actually, there's a bit of a confusion here: > XEP-0301 always use absolute cursor positioning for all action elements. > Cursor positioning has never been relative for XEP-0301. > No action element in XEP-0301 depended on the cursor position of the > previous action element. > > I suspect that your confusion might be caused by the fact that "n" is > relative, but "p" is always absolute. The omission of "p" simply means the > cursor is absolutely put at the end of the line (p = length of real time > message), as specified by section 4.5.1.3 "Rules for Attribute Values" > .... And section 4.5.3 say to always keep the cursor within the confines > of the real-time message. > http://xmpp.org/extensions/xep-0301.html#rules_for_attribute_values > > However, yes, I agree, this is probably confusing. I am now re-wording > things to try to clear up confusion; I will contact you later with a draft > wording to confirm, before submitting v0.2 of XEP-0301 to XSF. > You are right, I confused you, so I will fix the spec to avoid that. > At this point I'm actually very confused. Let me quote the published version of XEP-0301 again: "For <d> element (Forward Delete) and all other action elements, the cursor position is unaffected." So I would assume that (following that text) after performing <c p="0"/><d p="42"/> the cursor would remain at position "0". What you suggested appeared to me like you wanted this to move the cursor to position "42". That seems quite sensible to me, but would be a clear change from that text. Am I overlooking something? >> Interop problems are always unfortunate, but again I'd rather see them > > fixed than designing protocols to work around them. >> > > Agreed, agreed! > I do agree some justifications are not good (i.e. out-of-order message > delivery). > > However, the below fully justifies the usage of rudimentary (and mostly > optional) error recovery that XEP-0301 supports: > -- Wireless reception is not always good. We can't always do perfect > wireless signal. > -- And a group of us needs to meet requirements for mission-critical > reliability of Next Generation 9-1-1 > So, maybe I just live in a to idealistic mindset, but I have severe doubts that a terrible wireless signal can ever yield lost stanzas. That would not only imply that TCP packages were completely lost (no retransmits etc.), but also that they were lost in such a way that the stream's XML was still valid. For now I refuse to believe that until proven wrong. Mission-critical reliability is only really an issue if it is endangered. I've currently accepted that we need sequence numbers only because you're telling me that some XMPP servers perform congestion control that necessitates this (if that's the case, so be it). I've not yet heard any other plausible example of stanzas being lost. Regards, Florian Zeitz P.S.: Having seen your other mail. .de is in fact Germany, Denmark is .dk. Also I was fully aware of what 9-1-1 is, but thank you for thinking about local differences :).
