[Standards] Resource conflict handling
dave at cridland.net
Mon Jun 13 09:44:18 UTC 2011
On Mon Jun 13 10:08:58 2011, Glenn Maynard wrote:
> On Mon, Jun 13, 2011 at 4:04 AM, Dave Cridland <dave at cridland.net>
> > On Fri Jun 10 18:48:01 2011, Glenn Maynard wrote:
> >> This won't work properly if the existing client is a paused BOSH
> >> which may not unpause the session to reply for arbitrary lengths
> of time.
> > So it times out. No problem. Still works properly, everything's
> happy and
> > jolly.
> BOSH sessions may have pause sessions hours long. Taking an hour
> to time
> out isn't jolly, it's broken.
No, we don't wait for a response to time out. That's why it's called
"timing out". :-)
> Even the more common case of pauses on the order of minutes would
> be a
> clearly unacceptable delay. I don't think designing around expected
> timeouts is a good approach.
No, it's a fixed timeout in the order of ten seconds. There is
nothing a client can do (including explicitly pausing the session) to
> It's not one client involved, but two, and any time the right
> behaviour is
> > dependent on more than one entity doing things right, disaster
> lurks in the
> > wings.
> > If one client does it right, and another does it wrong, there's
> some nasty
> > failure cases.
> How is a buggy client ever going to accidentally conflict with a
> SHA-1 based
> resourcepart? (Or even something much shorter--you don't need 160
> bits to
> prevent that.) The point is using resourceparts designed to
> prevent these
> accidental conflicts.
Turn it around - how is your problem not solved by the solution
already in existence?
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards