Wait and inactivity time....

[netdude787]

Hi,

I am trying to increase wait time to a big value(180 sec) and according to node-xmpp logic I should bump up the inactivity time accordingly. Here is the code that is kicking in if I give wait time longer than inactivity.

if (this.wait <= 0 || this.wait > this.inactivity) {
    this.wait = Math.floor(this.inactivity * 0.8);
}

I am trying to understand why inactivity and wait time are coupled like this. According to standard, wait time is max allowed time for CM to respond to a request and inactivity is max allowed time for client without any request. These could be tuned independently, right? Where a longer poll time is desired for less frequent polls and at the same time CM should be able to quickly detect inactive clients.

Thanks for the help,

[dhruvbird]

According to xep-0124,

• 'wait' -- This is the longest time (in seconds) that the connection manager will wait before responding to any request during the session. The time MUST be less than or equal to the value specified in the session request.
• 'inactivity' -- This attribute specifies the longest allowable inactivity period (in seconds). This enables the client to ensure that the periods with no requests pending are never too long (see Polling Sessions and Inactivity).

So, it's clear that wait is a CM tunable and inactivity is a shared state variable. From my understanding of the XEP (which might be incorrect), it seems that inactivity is an upper bound on the max. allowed period of inactivity in both directions, so wait should be by definition < inactivity to ensure correct operation on either end.

Do let me know if that doesn't make sense, and we could discuss it further (closing for now).

[satyamshekhar]

IMHO by definition wait and inactivity are independent(I might be wrong). According to the XEP inactivity is the period when the CM is not holding any request(not related to bytes on wire). A client should wait for wait + inactivity to be sure that its session has been killed in case it just went idle.

However, having wait >> inactivity might be misleading since in case the client loses its connection to the CM(mobile clients) the time after which the session would be killed will be bounded by wait time instead on inactivity which IMHO is not in the spirit on the XEP.

[netdude787]

Thanks for prompt response. From my understanding basically you need a timer for client to detect CM disconnect which is wait-time and timer for CM to detect client disconnect which is inactivity-time. Since long-poll needs atleast one outstanding request from client at any time, as long as there is an outstanding request from client CM can assume client is alive. Once CM sends response to the pending (long-poll) request it needs a way to detect client disconnect, which is inactivity timer, time elapsed when it sends a last response(there is a mention of this in XEP standard).

If your definition of inactivity is an upperbound, do you start both wait & inactivity timers simultaneously when a new request is received from client? It really matters when these timers are started.

The role on inactivity on client side is breather time client can take to schedule its next request after it receives response from CM. Strophe.js is not using the inactivity on client side, because it schedules next request immediately after getting the response. Strophe just uses wait-time timer after sending request to detect CM disconnect, which is the right thing to do I think.

[satyamshekhar]

Yes inactivity timer is indeed reset-ed every time we receive a new request.

It might be a problem when wait time is very close to inactivity since the breather time for the client will be taken up by the wait time.

Resetting the inactivity when the response is sent instead of when request is received might make more sense.

My only concern is that wait time should not be an order of magnitude greater than the inactivity since that might make it confusing for client which would expect the session to be killed in O(inactivity time).

@dhruvbird what do you think?

[dhruvbird]

Since long-poll needs atleast one outstanding request from client at any time, as long as there is an outstanding request from client CM can assume client is alive.

This is not necessarily true. It isn't always possible to detect socket disconnection w/o actually sending/receiving something on the socket. Let's forget about keepalive for a bit. Even then, I am unsure if the socket's user-level code can detect it in a platform-neutral way.

If your definition of inactivity is an upperbound, do you start both wait & inactivity timers simultaneously when a new request is received from client? It really matters when these timers are started.

As @satyamshekhar mentioned, the inactivity timer is re-started every time a new request is received.

The role on inactivity on client side is breather time client can take to schedule its next request after it receives response from CM.

I would probably not interpret it as such. The client should ideally send out a new long-poll request immediately after receiving a response to a previously held request to ensure that if the server has anything to send, then it [the server] has the vehicles [the outstanding request] to put the data on.

Resetting the inactivity when the response is sent instead of when request is received might make more sense.

This might be a bad idea for unreliable networks. Plus, it's probably not what the XEP means.

[netdude787]

@dhruvbrid

"This might be a bad idea for unreliable networks. Plus, it's probably not what the XEP means."

Could you please elaborate on what you meant here, what breaks in unreliable network if timer is started after CM sends response?

Just wondering what scenario will not be detected in this case.

Also XEP definition says "Max time allowed with no requests", again starting timer after response to track request from a client is not going against the standard. I wish XEP had elaborated on these timers a little bit more the way routing protocols are drafted in IETF.

Also I have question wrt to node-xmpp implementation, sorry I could check the code but just wanted to quickly check. If I need two different poll times depending on the client device(for example mobile devices longer poll time is preferred), is this supported in node-xmpp?

For example, if I need poll times of 60 and 180 and configured inactivity is 200. Is upper bound timer still 200 for both clients or depends on the wait time?

Thanks for your time.

On Wed, Jan 2, 2013 at 11:19 AM, Dhruv Matani notifications@github.comwrote:

Since long-poll needs atleast one outstanding request from client at any time, as long as there is an outstanding request from client CM can assume client is alive.

This is not necessarily true. It isn't always possible to detect socket disconnection w/o actually sending/receiving something on the socket. Let's forget about keepalive for a bit. Even then, I am unsure if the socket's user-level code can detect it in a platform-neutral way.

If your definition of inactivity is an upperbound, do you start both wait & inactivity timers simultaneously when a new request is received from client? It really matters when these timers are started.

As @satyamshekhar https://github.com/satyamshekhar mentioned, the inactivity timer is re-started every time a new request is received.

The role on inactivity on client side is breather time client can take to schedule its next request after it receives response from CM.

I would probably not interpret it as such. The client should ideally send out a new long-poll request immediately after receiving a response to a previously held request to ensure that if the server has anything to send, then it [the server] has the vehicles [the outstanding request] to put the data on.

Resetting the inactivity when the response is sent instead of when request is received might make more sense.

This might be a bad idea for unreliable networks. Plus, it's probably not what the XEP means.

— Reply to this email directly or view it on GitHubhttps://github.com/dhruvbird/node-xmpp-bosh/issues/57#issuecomment-11800663.

[dhruvbird]

"This might be a bad idea for unreliable networks. Plus, it's probably not what the XEP means."

Could you please elaborate on what you meant here, what breaks in unreliable network if timer is started after CM sends response?

Just wondering what scenario will not be detected in this case.

Consider that the inactivity time is 60 sec, and the client dies just after sending the request. Suppose due to some reason, the socket disconnection is not detected when a response is sent, the CM will land up waiting 2x inactivity before declaring the client to be dead. This isn't necessarily bad, but results in too many connections on the CM (in case an attacker wants to exploit this behaviour).

Also XEP definition says "Max time allowed with no requests", again starting timer after response to track request from a client is not going against the standard. I wish XEP had elaborated on these timers a little bit more the way routing protocols are drafted in IETF.

I agree, but you can even interpret it as saying "Once I have a request held on the CM, what is the upper bound on the time I am willing to wait for the next request to come in before I declare the client to be dead."

I don't remember the implementation details off-hand, so I'll have a look at the code and get back to you.

[satyamshekhar]

Also I have question wrt to node-xmpp implementation, sorry I could check the code but just wanted to quickly check. If I need two different poll times depending on the client device(for example mobile devices longer poll time is preferred), is this supported in node-xmpp?

For example, if I need poll times of 60 and 180 and configured inactivity is 200. Is upper bound timer still 200 for both clients or depends on the wait time?

Assuming you meant node-xmpp-bosh instead of node-xmpp.

We support configurable inactivity. You can send an attribute inactivity='60' or inactivity='180' in the session creation request to set the inactivity for the session. Make sure that the requested value of inactivity lies between max_inactivity and default_inactivity, since these are the upper and lower bounds. (see bosh.conf.example.js in root directory).

[dhruvbird]

@satyamshekhar has the right information. Inactivity is configurable, and so is wait, but the bounds need to be maintained.

For example, if I need poll times of 60 and 180 and configured inactivity is 200. Is upper bound timer still 200 for both clients or depends on the wait time?

Off the top of my head, I believe we have NOT tested NXB with a polling based client (only with clients that support long polling), so when you say polling time, I am assuming you mean wait time.