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.
We need the full jid but it seems we are alone, so I see no point in
fighting for that.
--
Mickaël Rémond
http://www.process-one.net/
Le 6 mars 09 à 13:28, Dave Cridland <[email protected]> a écrit :
On Fri Mar 6 11:45:06 2009, Mickael Remond wrote:
Dave Cridland wrote:
> On Thu Mar 5 18:19:53 2009, Mickael Remond wrote:
> > So do we all agree that either way (using jid on resume or
starting
> > stream management after bind), the XEP needs to be modified ?
> Not on this basis, no.
Ok, so we do not agree.
XEP-0198 is thus not what you need and it looks that we will need to
write our own protocol to resume sessions.
I'm missing your logic, here.
You're saying that a full jid is required to locate the node,
because you have a distributed lookup table from full jid to node,
and you don't want another lookup table.
I'm saying you don't *need* another lookup table, or at the very
least you'd only need one that varied according to the nodes in the
cluster, which, one hopes, is not very volatile.
A concrete example (although possibly not tremendously realistic):
A cluster "jabber.org" consisting of two nodes, "hermes" and "athena".
If I acquire a sm-id from a connection to hermes, then I get, for
example "hermes:asudhguilh". One from athena similar begins
"athena:". The remainder would be made up of some node-local lookup
key and a MAC, most likely.
Neither Hermes nor Athena need a complete list of sessions at any
time, they merely need a list of nodes, which one assumes rather
rashly that they already have, and a method for string
representation of these nodes. (I chose hostnames, but I imagine a
real clustering solution would use something rather more specific,
like a communications endpoint - in addition, I'd except all nodes
within a cluster to be able to verify the sm-id, but that's trivial).
This strategy allows a session to be uniquely named easily, without
additional shared state, and allows a common protocol for both C2S
and S2S sessions.
What am I missing that this doesn't solve?
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
