Re: [Standards] XEP-0198 suggestion (Stream management)
Hello, Peter Saint-Andre wrote: And then a section that talks about the id, how it's opaque to the initiating entity, that any characters allowed in an XML attribute may be used, it must not be reused, and that it has a max size of say... 4k. If Mickael wants to encode his id as the full JID plus a nonce, he can. Mickael, does that work for you? Yes, it does. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
On 3/13/09 1:58 AM, Mickael Remond wrote: Hello, Peter Saint-Andre wrote: And then a section that talks about the id, how it's opaque to the initiating entity, that any characters allowed in an XML attribute may be used, it must not be reused, and that it has a max size of say... 4k. If Mickael wants to encode his id as the full JID plus a nonce, he can. Mickael, does that work for you? Yes, it does. Great! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0198 suggestion (Stream management)
On 3/12/09 10:06 PM, Joe Hildebrand wrote: On Mar 12, 2009, at 4:29 PM, Peter Saint-Andre wrote: The phrase when the server gives stream features for resumption could mean two things: 1. Whenever a server that supports stream resumption sends stream features. OR 2. When a server sends stream features to an initiating entity that is attemping to resume a session. Given that #2 involves mind-reading, I think we mean #1. But isn't it possible that the host+port to which a client reconnects is not known at the time the server sends stream features? (The exception would seem to be that the server sends the client to some kind of load balancer.) How about this: C: enable xmlns='urn:xmpp:sm:0'/ S: enabled xmlns='urn:xmpp:sm:0' resume='1' id='some-long-id' host='foo.example.com' port='5222'/ WFM. I will try to finish my edits to XEP-0198 today. Other than the clarifications we've discussed, I'm working to improve the error handling and also add some more detailed scenarios so that we have a lot more examples. We Put the Example in Example.com! [tm] Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0198 suggestion (Stream management)
Sorry, just catching up on the thread. An interesting discussion. :) On 3/7/09 10:45 AM, Joe Hildebrand wrote: On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote: On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote: I actually think that moving stream management after the bind is a good thing. Much more flexible, and a relatively minor change. I think moving sm-id generation - which is the real issue - until after resumable sessions are enabled, and explicitly making sm-id a one-use resume ticket, is certainly a good idea. I think restricting the protocol to C2S is a bad idea. OK, fine. And I see what you're getting at in your other mail. So we'd do this: S: stream:features bind xmlns='urn:ietf:params:xml:ns:xmpp-bind' required/ /bind sm xmlns='urn:xmpp:sm:0' max='15' stanzas='4' optional/ /sm /stream:features C: iq id='bind_1' type='set' bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/ /iq S: iq id='bind_1' type='result' bind xmlns='urn:ietf:params:xml:ns:xmpp-bind' jid jul...@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb /jid /bind /iq C: enable xmlns='urn:xmpp:sm:0'/ S: enabled xmlns='urn:xmpp:sm:0' resume='1' id='some-long-id'/ Yes, that seems reasonable. For s2s the sm-id would be generated after SASL EXTERNAL, for c2s after resource binding. Then I think all that is needed is couple of sentences in section 2 that says something like: All other stream features offered along with the stream management feature which the initiating entity wishes to process MUST be processed before the stream management feature. This will typically mean that you bind your resource BEFORE you initiate stream management on client-to-server streams. Something like that, yes. I can wordsmith. And then a section that talks about the id, how it's opaque to the initiating entity, that any characters allowed in an XML attribute may be used, it must not be reused, and that it has a max size of say... 4k. If Mickael wants to encode his id as the full JID plus a nonce, he can. Mickael, does that work for you? I didn't get what you said after this, because the first part didn't really make sense to me. Are you suggesting that we do XEP-198 on S2S connections? Why bother? They're close enough to stateless that we shouldn't perturb -198 will new requirements. Reliability, not optimization. Got it. Ditto. - When the server gives stream features for resumption, it MAY include a hostname/IP and port on which to reconnect. This allows some flexibility of deployment. Right, that's possible, although I'd suggest we actually made the default to reconnect on the same address as before (ie, the same IP address and port). If the server doesn't specify, then yes, SHOULD connect back to the same IP/port. Agreed. When you're deployed behind a load balancer, the client doesn't have enough info to do that, however. So then the server needs to be smart. - Server gives the client a max number of stanzas between acknowledgements. That way the server can have some control over what it needs to buffer. Good point. - Server tells the client the maximum amount of time it will keep the session around after disconnection, in seconds. If the client can't get reconnected in that timeframe, it can drop its state. I think we do this already? Oops. I missed that. There should probably be a little more text that describes the consequences of max. Is minutes enough resolution? I don't have a strong opinion about that. I think seconds is better. It seems to me that it might be less than a minute. - Clients SHOULD NOT send ack requests back-to-back, without intervening stanzas. It's equivalent to a ping, I don't see the harm here. Specifically, while I can see reasons not to do this, I can't see what would cause interop problems. Hm. Why do we need the pings as separate protocol, then? We don't. We wrote the XMPP Ping stuff because people weren't as friendly to Stream Management (Stanza Acking) back then. I will endeavor to update XEP-0198 today or tomorrow so that we all have a clearer vision of the protocol. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0198 suggestion (Stream management)
On 3/12/09 8:03 AM, Peter Saint-Andre wrote: On 3/7/09 10:45 AM, Joe Hildebrand wrote: On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote: On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote: - When the server gives stream features for resumption, it MAY include a hostname/IP and port on which to reconnect. This allows some flexibility of deployment. Right, that's possible, although I'd suggest we actually made the default to reconnect on the same address as before (ie, the same IP address and port). If the server doesn't specify, then yes, SHOULD connect back to the same IP/port. Agreed. The phrase when the server gives stream features for resumption could mean two things: 1. Whenever a server that supports stream resumption sends stream features. OR 2. When a server sends stream features to an initiating entity that is attemping to resume a session. Given that #2 involves mind-reading, I think we mean #1. But isn't it possible that the host+port to which a client reconnects is not known at the time the server sends stream features? (The exception would seem to be that the server sends the client to some kind of load balancer.) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0198 suggestion (Stream management)
On Mar 12, 2009, at 4:29 PM, Peter Saint-Andre wrote: The phrase when the server gives stream features for resumption could mean two things: 1. Whenever a server that supports stream resumption sends stream features. OR 2. When a server sends stream features to an initiating entity that is attemping to resume a session. Given that #2 involves mind-reading, I think we mean #1. But isn't it possible that the host+port to which a client reconnects is not known at the time the server sends stream features? (The exception would seem to be that the server sends the client to some kind of load balancer.) How about this: C: enable xmlns='urn:xmpp:sm:0'/ S: enabled xmlns='urn:xmpp:sm:0' resume='1' id='some-long-id' host='foo.example.com' port='5222'/
Re: [Standards] XEP-0198 suggestion (Stream management)
On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote: I actually think that moving stream management after the bind is a good thing. Much more flexible, and a relatively minor change. I think moving sm-id generation - which is the real issue - until after resumable sessions are enabled, and explicitly making sm-id a one-use resume ticket, is certainly a good idea. I think restricting the protocol to C2S is a bad idea. I didn't get what you said after this, because the first part didn't really make sense to me. Are you suggesting that we do XEP-198 on S2S connections? Why bother? They're close enough to stateless that we shouldn't perturb -198 will new requirements. Reliability, not optimization. - When the server gives stream features for resumption, it MAY include a hostname/IP and port on which to reconnect. This allows some flexibility of deployment. Right, that's possible, although I'd suggest we actually made the default to reconnect on the same address as before (ie, the same IP address and port). - Server gives the client a max number of stanzas between acknowledgements. That way the server can have some control over what it needs to buffer. Good point. - Server tells the client the maximum amount of time it will keep the session around after disconnection, in seconds. If the client can't get reconnected in that timeframe, it can drop its state. I think we do this already? - Clients SHOULD NOT send ack requests back-to-back, without intervening stanzas. It's equivalent to a ping, I don't see the harm here. Specifically, while I can see reasons not to do this, I can't see what would cause interop problems. 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
Re: [Standards] XEP-0198 suggestion (Stream management)
Dave Cridland wrote: On Fri Mar 6 06:39:19 2009, Curtis King wrote: The xep needs some filling out or maybe be split into two separate xeps. IMHO, resuming a session is only useful for C2S connections. Why bother with S2S connections. Resuming S2S sessions is mostly concerned with reliability, rather than optimization. It means that servers can avoid any stanza-loss due to a connection drop. (In principle, this shouldn't be possible now, but in practice, it seems to happen on occasion). And did anyone ever investigate why this happens? I doubt that the majority of those 'lost stanzas' is physically lost. Incorrect handling of 'bounces' when a S2S connection does not get established for some reason seems much more likely to me. For example: presence type='subscribe'/ to some remote entity bounces. The bare jid gets a presence type='error'/, but does associate this with the subscribe. Besides which, S2S has long been seen as the deployment path - a server doing XEP-0198 on both S2S and C2S can at least self-interop from the outset with S2S. 0198 is not usable on s2s unless you're using sasl, because it does not get offered before the initiator has been authenticated? philipp
Re: [Standards] XEP-0198 suggestion (Stream management)
On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote: On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote: I actually think that moving stream management after the bind is a good thing. Much more flexible, and a relatively minor change. I think moving sm-id generation - which is the real issue - until after resumable sessions are enabled, and explicitly making sm-id a one-use resume ticket, is certainly a good idea. I think restricting the protocol to C2S is a bad idea. OK, fine. And I see what you're getting at in your other mail. So we'd do this: S: stream:features bind xmlns='urn:ietf:params:xml:ns:xmpp-bind' required/ /bind sm xmlns='urn:xmpp:sm:0' max='15' stanzas='4' optional/ /sm /stream:features C: iq id='bind_1' type='set' bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/ /iq S: iq id='bind_1' type='result' bind xmlns='urn:ietf:params:xml:ns:xmpp-bind' jid jul...@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb /jid /bind /iq C: enable xmlns='urn:xmpp:sm:0'/ S: enabled xmlns='urn:xmpp:sm:0' resume='1' id='some-long-id'/ Then I think all that is needed is couple of sentences in section 2 that says something like: All other stream features offered along with the stream management feature which the initiating entity wishes to process MUST be processed before the stream management feature. This will typically mean that you bind your resource BEFORE you initiate stream management on client-to-server streams. And then a section that talks about the id, how it's opaque to the initiating entity, that any characters allowed in an XML attribute may be used, it must not be reused, and that it has a max size of say... 4k. If Mickael wants to encode his id as the full JID plus a nonce, he can. I didn't get what you said after this, because the first part didn't really make sense to me. Are you suggesting that we do XEP-198 on S2S connections? Why bother? They're close enough to stateless that we shouldn't perturb -198 will new requirements. Reliability, not optimization. Got it. - When the server gives stream features for resumption, it MAY include a hostname/IP and port on which to reconnect. This allows some flexibility of deployment. Right, that's possible, although I'd suggest we actually made the default to reconnect on the same address as before (ie, the same IP address and port). If the server doesn't specify, then yes, SHOULD connect back to the same IP/port. When you're deployed behind a load balancer, the client doesn't have enough info to do that, however. - Server gives the client a max number of stanzas between acknowledgements. That way the server can have some control over what it needs to buffer. Good point. - Server tells the client the maximum amount of time it will keep the session around after disconnection, in seconds. If the client can't get reconnected in that timeframe, it can drop its state. I think we do this already? Oops. I missed that. There should probably be a little more text that describes the consequences of max. Is minutes enough resolution? I don't have a strong opinion about that. - Clients SHOULD NOT send ack requests back-to-back, without intervening stanzas. It's equivalent to a ping, I don't see the harm here. Specifically, while I can see reasons not to do this, I can't see what would cause interop problems. Hm. Why do we need the pings as separate protocol, then? -- Joe Hildebrand
Re: [Standards] XEP-0198 suggestion (Stream management)
On Fri Mar 6 06:39:19 2009, Curtis King wrote: The xep needs some filling out or maybe be split into two separate xeps. IMHO, resuming a session is only useful for C2S connections. Why bother with S2S connections. Resuming S2S sessions is mostly concerned with reliability, rather than optimization. It means that servers can avoid any stanza-loss due to a connection drop. (In principle, this shouldn't be possible now, but in practice, it seems to happen on occasion). Besides which, S2S has long been seen as the deployment path - a server doing XEP-0198 on both S2S and C2S can at least self-interop from the outset with S2S. 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
Re: [Standards] XEP-0198 suggestion (Stream management)
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 d...@cridland.net 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: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
Re: [Standards] XEP-0198 suggestion (Stream management)
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
Re: [Standards] XEP-0198 suggestion (Stream management)
On Mar 6, 2009, at 12:40 PM, 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. So maybe this is the real problem. If we allow a new sm-id to be set in the middle of a session (maybe in the stream:error /), maybe thats a solution for a lot of other use- cases. For example: * you decide to gracefully shutdown a node - for each open connection, send the stream:error with a new sm-id; * your cluster decides to rebalance some users to another node - close the connection, include the new sm-id. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: m...@simplicidade.org Use XMPP!
Re: [Standards] XEP-0198 suggestion (Stream management)
On Mar 5, 2009, at 5:11 PM, 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. I actually think that moving stream management after the bind is a good thing. Much more flexible, and a relatively minor change. Sorry, I *knew* something was nagging me about all this... We also need to deal with S2S sessions, I didn't get what you said after this, because the first part didn't really make sense to me. Are you suggesting that we do XEP-198 on S2S connections? Why bother? They're close enough to stateless that we shouldn't perturb -198 will new requirements. While we're on the subject, there are a few changes I'd like to see as well: - When the server gives stream features for resumption, it MAY include a hostname/IP and port on which to reconnect. This allows some flexibility of deployment. - Server gives the client a max number of stanzas between acknowledgements. That way the server can have some control over what it needs to buffer. - Server tells the client the maximum amount of time it will keep the session around after disconnection, in seconds. If the client can't get reconnected in that timeframe, it can drop its state. - Clients SHOULD NOT send ack requests back-to-back, without intervening stanzas. -- Joe Hildebrand
Re: [Standards] XEP-0198 suggestion (Stream management)
Hi, On Feb 27, 2009, at 1:50 PM, Mickael Remond wrote: Dave Cridland wrote: On Thu Feb 26 21:40:44 2009, Fabio Forno wrote: On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond mickael.rem...@process-one.net wrote: With the JID you can simply reconnect to the existing running session without having another shared state. It makes a big difference for large scale deployment with clustering support. In this stanza? resume xmlns='urn:xmpp:sm:0' previd='some-long-sm-id'/ Do you mean using the full jid instead of the previd or in addition? If it's just the jid it can work only if the server sets a resource with some random data, otherwise it becomes extremely easy to hijack a sesssion What I suggest is to have both the jid and the session id. Because the server chooses the sm-id, it can encode the full jid into it if needs be. My point was to avoid giving meaning to opaque data. In my view, opaque is applied to the client point of view. I have no problems that a field, generated by the server, and only used by the same server (server here could mean a set of servers working together) has some meaning to it. I would imagine for example, that I could have a sm-id as ID,HMAC where I can check if the ID was not tampered with. The sm-id is opaque to the client and has meaning to the server. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: m...@simplicidade.org Use XMPP!
Re: [Standards] XEP-0198 suggestion (Stream management)
Hello, Pedro Melo wrote: In my view, opaque is applied to the client point of view. I have no problems that a field, generated by the server, and only used by the same server (server here could mean a set of servers working together) has some meaning to it. I would imagine for example, that I could have a sm-id as ID,HMAC where I can check if the ID was not tampered with. The sm-id is opaque to the client and has meaning to the server. Yes, but the problem is that this decision adds yet another routing criteria on the server (looking up where is the session you want to resume is a routing algorithm). Most of the routing on the server is done through JID and you have all the infrastructure in place on the server to cope with that. Using another new id is creating a new routing criteria. Why O why do we need that :) We have seen from previous comment that you cannot use full JID in this opaque data, because that's an information you do not have at the time you generate the sm-id. So, you have to build another routing table at the implementation level. I have been given many reason why the sm-id was something sufficent enough, but no reason explaining why requiring the full JID to resume a session was a bad design decision. sm-id is an access key. We still need to specify which session you are resuming. This is two different needs and I do not see any good reason not to acknowledge that in the protocol. Yes, you could hack something mixing the two (let's suppose for an instant it could work), but why not make it clear that both information are important from the beginning ? I feel a bit alone to defend this view, and I am suddently afraid to have been struck by early Elzeimer disease :) -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
On 5-Mar-09, at 8:41 AM, Mickael Remond wrote: So, you have to build another routing table at the implementation level. I have been given many reason why the sm-id was something sufficent enough, but no reason explaining why requiring the full JID to resume a session was a bad design decision. resource conflict, using just the full jid would not handle this situation. You need something else to make sure you are resuming the correct session for the correct client. So, the id needs to-be something opaque and non-deterministic to the client. I agree with you, that the server would want to use the full jid in some way to produce the id, so you could just use the existing routing tables to find the session. All, we need to-do this is to require a bind first before stream management. This would add no additional steps for the clients. Setup would be, 1. Client authenticates. 2. Client Binds. 3. Client starts stream management, gets back sm-id 4. Client gets roster, sends presence, etc. Session drops.. Resume would be, 1. Client authenticates. 2. Client starts stream management by resuming using sm-id. If a client can't get to step 3 in the setup then it's not losing anything if the session drops. I'm assuming a client always needs to authenticate. ck
Re: [Standards] XEP-0198 suggestion (Stream management)
On Thu Mar 5 17:16:44 2009, Curtis King wrote: On 5-Mar-09, at 8:41 AM, Mickael Remond wrote: So, you have to build another routing table at the implementation level. I have been given many reason why the sm-id was something sufficent enough, but no reason explaining why requiring the full JID to resume a session was a bad design decision. resource conflict, using just the full jid would not handle this situation. You need something else to make sure you are resuming the correct session for the correct client. So, the id needs to-be something opaque and non-deterministic to the client. XEP-0198 can restore a session after the server has noticed the TCP session down, in principle, in which case the full_jid is unroutable, and actually available for another session if one gets there first - it's possible that in some cases, a client might even still want to know whether its dropped connection at least sent all the messages when it hits a conflict. I agree with you, that the server would want to use the full jid in some way to produce the id, so you could just use the existing routing tables to find the session. I'm inclined to agree, but I suspect you'd still need to share state on what sessions were available by session id, which'd somewhat obviate the need for including the full jid. But I'll admit I might be making this more complex than it really needs to be, and besides which, if the full jid is needed by the server, it can be encoded in and recovered from the sm-id. All, we need to-do this is to require a bind first before stream management. This would add no additional steps for the clients. Setup would be, 1. Client authenticates. 2. Client Binds. 3. Client starts stream management, gets back sm-id Could this step be the session/ we all love to hate? (RFC 3920 section 3, if, like me, you'd forgotten about it). It's the right place, after all. 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
Re: [Standards] XEP-0198 suggestion (Stream management)
Hello, Curtis King wrote: On 5-Mar-09, at 8:41 AM, Mickael Remond wrote: So, you have to build another routing table at the implementation level. I have been given many reason why the sm-id was something sufficent enough, but no reason explaining why requiring the full JID to resume a session was a bad design decision. resource conflict, using just the full jid would not handle this situation. You need something else to make sure you are resuming the correct session for the correct client. So, the id needs to-be something opaque and non-deterministic to the client. The resource conflict is still handled / enforced on opening new session. And if the session you want to resume has been kicked due to resource conflict, sm-id will not match, so your session resume will not work. I agree with you, that the server would want to use the full jid in some way to produce the id, so you could just use the existing routing tables to find the session. All, we need to-do this is to require a bind first before stream management. This would add no additional steps for the clients. Setup would be, 1. Client authenticates. 2. Client Binds. 3. Client starts stream management, gets back sm-id 4. Client gets roster, sends presence, etc. Session drops.. Resume would be, 1. Client authenticates. 2. Client starts stream management by resuming using sm-id. If a client can't get to step 3 in the setup then it's not losing anything if the session drops. I'm assuming a client always needs to authenticate. Yes, that's a possible option as well. So do we all agree that either way (using jid on resume or starting stream management after bind), the XEP needs to be modified ? -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
On 5-Mar-09, at 10:19 AM, Mickael Remond wrote: resource conflict, using just the full jid would not handle this situation. You need something else to make sure you are resuming the correct session for the correct client. So, the id needs to-be something opaque and non-deterministic to the client. The resource conflict is still handled / enforced on opening new session. And if the session you want to resume has been kicked due to resource conflict, sm-id will not match, so your session resume will not work. I'm confused by this comment. You say you want to use the full jid for resumption yet you refer to using the sm-id which I said you need to use. If you have the sm-id then you don't need the full jid, but it's moot anyways as to have the full jid the client needs to bind first. Passing both the full jid and sm-id is not a big deal, even though the server could encode the jid into the sm-id in deterministic way to it. With resource conflict and stream management you most likely don't want to kick the old session as the original client will want to resume it. There should a timeout for how long the sm-id is valid for. ck
Re: [Standards] XEP-0198 suggestion (Stream management)
On 5-Mar-09, at 9:55 AM, Dave Cridland wrote: XEP-0198 can restore a session after the server has noticed the TCP session down, in principle, in which case the full_jid is unroutable, and actually available for another session if one gets there first - it's possible that in some cases, a client might even still want to know whether its dropped connection at least sent all the messages when it hits a conflict. I would argue you do want this behavior if a client has asked for stream management. You want to keep that full jid alive and routable so the client can reconnect and resume the session. Kinda the whole is it not? ck
Re: [Standards] XEP-0198 suggestion (Stream management)
Hello Curtis, Curtis King wrote: On 5-Mar-09, at 10:19 AM, Mickael Remond wrote: The resource conflict is still handled / enforced on opening new session. And if the session you want to resume has been kicked due to resource conflict, sm-id will not match, so your session resume will not work. I'm confused by this comment. You say you want to use the full jid for resumption yet you refer to using the sm-id which I said you need to use. If you have the sm-id then you don't need the full jid, but it's moot anyways as to have the full jid the client needs to bind first. Passing both the full jid and sm-id is not a big deal, even though the server could encode the jid into the sm-id in deterministic way to it. You need both full-jid and sm-id. My previous post mention that full jid is needed for routing (finding the session) and sm-id is needed as access key. With resource conflict and stream management you most likely don't want to kick the old session as the original client will want to resume it. There should a timeout for how long the sm-id is valid for. If the session you want to resume as been kicked, you probably want to not allow resuming with old key. Yes, there should be a timeout if no one ever resume. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
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. Sorry, I *knew* something was nagging me about all this... We also need to deal with S2S sessions, which have (one or more) domain-form full jids, and in a cluster it's perfectly reasonable to have multiple S2S sessions to different nodes from the same domain. (Unusual, perhaps, but perfectly legal, as far as I can see). Moreover, the return route may be on a different cluster node than the inbound route[s], so your routing table might not help at all, and there *is* no bind. So I still maintain that you need to figure out the node based purely on the session id. Of course, that's easily done without worrying about the full jid at all, you simply need to encode in a node identifier - that could be the node's address, host, uuid, or whatever else is convenient. In summary: a) The full jid won't always help. b) There's always something else you can encode into the sm-id to help you locate the node again. 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
Re: [Standards] XEP-0198 suggestion (Stream management)
You seem to-be missing what I'm saying on both points, On 5-Mar-09, at 12:29 PM, Mickael Remond wrote: You need both full-jid and sm-id. My previous post mention that full jid is needed for routing (finding the session) and sm-id is needed as access key. The sm-id can include the full jid, you only need the sm-id. But, I agree it would helpful to server developers to have access to the full jid when generating the sm-id. With resource conflict and stream management you most likely don't want to kick the old session as the original client will want to resume it. There should a timeout for how long the sm-id is valid for. If the session you want to resume as been kicked, My point is you do not want to kick a session which is being manages, as the want to resume it at some point. you probably want to not allow resuming with old key. That is stating the obvious. The xep needs some filling out or maybe be split into two separate xeps. IMHO, resuming a session is only useful for C2S connections. Why bother with S2S connections. ck
Re: [Standards] XEP-0198 suggestion (Stream management)
On 28-Feb-09, at 11:49 AM, Justin Karneges wrote: On Saturday 28 February 2009 10:59:57 Curtis King wrote: On 28-Feb-09, at 6:10 AM, Mickael Remond wrote: I still think requiring the full JID is the best approach as it maps with how to locate a session in the server when sending a message to a client. I think that an more reasonable requirement would be session management can not be enabled until after a bind and a re-bind could cause a new sm-id to-be issued. This way servers would have all available to them to generate what ever sm-id they want. It actually make more sense to only enable session management after a bind. Given that you can bind multiple resources in a single XMPP-Core session, it probably makes more sense to keep the session management before binding. If you resume a session, then all resources are resumed. This also means that the session management id has a 1-to-many relationship with full JIDs. It still can even when you require the session management after a bind. Besides session management before a bind makes no sense as you aren't saving anything. I don't know if it is written in the XEP this way yet, but the intent is that once you resume the session, you don't have to bind, request the roster, or send initial presence again. The entire state of the session is restored as it was before connection loss. I think that is obvious :-) ck
Re: [Standards] XEP-0198 suggestion (Stream management)
On 28-Feb-09, at 6:10 AM, Mickael Remond wrote: I still think requiring the full JID is the best approach as it maps with how to locate a session in the server when sending a message to a client. I think that an more reasonable requirement would be session management can not be enabled until after a bind and a re-bind could cause a new sm-id to-be issued. This way servers would have all available to them to generate what ever sm-id they want. It actually make more sense to only enable session management after a bind. ck
Re: [Standards] XEP-0198 suggestion (Stream management)
On Saturday 28 February 2009 10:59:57 Curtis King wrote: On 28-Feb-09, at 6:10 AM, Mickael Remond wrote: I still think requiring the full JID is the best approach as it maps with how to locate a session in the server when sending a message to a client. I think that an more reasonable requirement would be session management can not be enabled until after a bind and a re-bind could cause a new sm-id to-be issued. This way servers would have all available to them to generate what ever sm-id they want. It actually make more sense to only enable session management after a bind. Given that you can bind multiple resources in a single XMPP-Core session, it probably makes more sense to keep the session management before binding. If you resume a session, then all resources are resumed. This also means that the session management id has a 1-to-many relationship with full JIDs. I don't know if it is written in the XEP this way yet, but the intent is that once you resume the session, you don't have to bind, request the roster, or send initial presence again. The entire state of the session is restored as it was before connection loss. -Justin
Re: [Standards] XEP-0198 suggestion (Stream management)
On Thu, Feb 26, 2009 at 10:47 PM, Dave Cridland d...@cridland.net wrote: Because the server chooses the sm-id, it can encode the full jid into it if needs be. Yep that was what I meant. BTW: is there in same place (rfcs, xeps) a recommendation saying that relying on a resource set by clients is a bad idea? -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0198 suggestion (Stream management)
Hello, Dave Cridland wrote: On Thu Feb 26 21:40:44 2009, Fabio Forno wrote: On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond mickael.rem...@process-one.net wrote: With the JID you can simply reconnect to the existing running session without having another shared state. It makes a big difference for large scale deployment with clustering support. In this stanza? resume xmlns='urn:xmpp:sm:0' previd='some-long-sm-id'/ Do you mean using the full jid instead of the previd or in addition? If it's just the jid it can work only if the server sets a resource with some random data, otherwise it becomes extremely easy to hijack a sesssion What I suggest is to have both the jid and the session id. Because the server chooses the sm-id, it can encode the full jid into it if needs be. My point was to avoid giving meaning to opaque data. Yes, we can do that, but if it is a good practice and a usefull information for several server, I think we can expect the XEP to promote that. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
Hello, Fabio Forno wrote: Yep that was what I meant. BTW: is there in same place (rfcs, xeps) a recommendation saying that relying on a resource set by clients is a bad idea? I am not sure I understand what you mean. The client is choosing the resource. That's by definition a client provided information. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
On Fri, Feb 27, 2009 at 2:51 PM, Mickael Remond mickael.rem...@process-one.net wrote: Yep that was what I meant. BTW: is there in same place (rfcs, xeps) a recommendation saying that relying on a resource set by clients is a bad idea? I am not sure I understand what you mean. The client is choosing the resource. That's by definition a client provided information. Found! http://xmpp.org/rfcs/rfc3920.html#bind It's already specified: the server may override the resource (some, as google, do): A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates; in this case, the server SHOULD NOT return a stanza error (e.g., forbidden/) to the client but instead SHOULD communicate the generated resource identifier to the client in the IQ result as shown above -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0198 suggestion (Stream management)
On Fri Feb 27 13:50:05 2009, Mickael Remond wrote: My point was to avoid giving meaning to opaque data. Yes, we can do that, but if it is a good practice and a usefull information for several server, I think we can expect the XEP to promote that. No, I disagree, the sm-id is allocated by the server, the server can put as much meaning into it as it wants. It's still opaque to the client. If the server's implementation means that it needs to have access to the full jid, then it should encode that into the sm-id. There is abolutely no need at all to make such encoding interoperable. 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
Re: [Standards] XEP-0198 suggestion (Stream management)
Le 27 févr. 09 à 15:34, Dave Cridland a écrit : No, I disagree, the sm-id is allocated by the server, the server can put as much meaning into it as it wants. It's still opaque to the client. If the server's implementation means that it needs to have access to the full jid, then it should encode that into the sm-id. There is abolutely no need at all to make such encoding interoperable. Except promoting good practice.
Re: [Standards] XEP-0198 suggestion (Stream management)
Hello, Dave Cridland wrote: No, I disagree, the sm-id is allocated by the server, the server can put as much meaning into it as it wants. It's still opaque to the client. If I read the spec correctly the stream feature packet that contains the sm-id is send before the bind, right ? So, you do not have the full JID (you miss the resource) at this time and as a result, cannot include it as a server in the sm-id. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
On Fri Feb 27 15:41:39 2009, Mickael Remond wrote: If I read the spec correctly the stream feature packet that contains the sm-id is send before the bind, right ? So, you do not have the full JID (you miss the resource) at this time and as a result, cannot include it as a server in the sm-id. Well, that's true, but you just encode in whatever else makes sense to relocate the session. We'd be using a node URI and session number tuple, probably. 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
[Standards] XEP-0198 suggestion (Stream management)
Hello, As a follow-up of the latest XMPP summit in Brussels, we would like to request a small but useful addition to XEP-0198. The feedback is in session resumption: Is it possible to require the client to pass the full JID of the session being resumed ? With the JID you can simply reconnect to the existing running session without having another shared state. It makes a big difference for large scale deployment with clustering support. Thank you ! -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] XEP-0198 suggestion (Stream management)
On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond mickael.rem...@process-one.net wrote: Hello, As a follow-up of the latest XMPP summit in Brussels, we would like to request a small but useful addition to XEP-0198. The feedback is in session resumption: Is it possible to require the client to pass the full JID of the session being resumed ? With the JID you can simply reconnect to the existing running session without having another shared state. It makes a big difference for large scale deployment with clustering support. In this stanza? resume xmlns='urn:xmpp:sm:0' previd='some-long-sm-id'/ Do you mean using the full jid instead of the previd or in addition? If it's just the jid it can work only if the server sets a resource with some random data, otherwise it becomes extremely easy to hijack a sesssion -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0198 suggestion (Stream management)
On Thu Feb 26 21:40:44 2009, Fabio Forno wrote: On Thu, Feb 26, 2009 at 5:05 PM, Mickael Remond mickael.rem...@process-one.net wrote: With the JID you can simply reconnect to the existing running session without having another shared state. It makes a big difference for large scale deployment with clustering support. In this stanza? resume xmlns='urn:xmpp:sm:0' previd='some-long-sm-id'/ Do you mean using the full jid instead of the previd or in addition? If it's just the jid it can work only if the server sets a resource with some random data, otherwise it becomes extremely easy to hijack a sesssion Because the server chooses the sm-id, it can encode the full jid into it if needs be. 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
