Hello, Dave Cridland wrote:
> 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. Nothing in the spec says that you will get stream features from the resuming session, nor how it will happen. Resuming is simply about sending a resume packet. That's it. Nothing in the spec allows you to use full JID in the sm-id (by the way the packet are ordered. > 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. Yes, exactely. I think the current spec can simply not be implement. It need to be improved. > 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? The only problem is, like I said, we need a new version of the spec (because current version does not work for us). We really prefer having a way to pass the full JID. It is nice reuse of existing information, I think. Note that by making the sm-id the look up value _and_ the access key, it mean that you need a new indexed field in your session table (because routing is base on full jid, where session resuming look up will be perform on another field). Using full JID to find the information and check checking that key is correct allows you to look up on the same routing value. There is one case that you still cannot handle with this approach: What is the node has been shutdown and session has been moved to another node ? You simply cannot find it in your case. I think there is several other problems as well. For example, how do you make sure that client and server agree on the from attribute that will be used ? What if the client expect to use another JID or another resource that the one the server has in memory ? It needs to be detected in some way if there is a discrepency. Anyway, my point is that we probably need to implement it our way before the spec is ready. -- Mickaël Rémond http://www.process-one.net/
