On Fri Mar 6 12:40:27 2009, Mickaël Rémond wrote:
By harcoding the node in sm-id, who is immutable during the session
you cannot move the session to the node the user is resuming the
session. It will not work on second resume.
Right, I see.
I'd actually thought that the sm-id you'd use in a subsequent
resumption would be the sm-id from the last stream - the sm-id is
given in the stream features, so by saying you want to resume the
stream, you'd presumably use the last one given, rather than the
first.
This mean that a given sm-id can only be used once, and the new node
would be giving one of its own sm-id's for "next time".
However, there's a problem or two here - firstly, this isn't clear in
the spec.
Secondly, a sm-id more or less has to be random and authenticated, so
there's going to be a real cost associated with generating them, and
that could be used to drain the random resource. (There's ways around
this, but still).
It seems to me that a sm-id needs only to be provided either when
resumption is enabled or used. Then that ought to work fine for
ejabberd, right?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
