Using 'wait' instead of 'inactivity'?
guusdk opened this issue · comments
As per conversation in Converse's support MUC: it seems that Strophe is using the 'wait' attribute value where it should be using the 'inactivity' value of a BOSH session.
From the XEP:
7.1 Session Creation Request
(...)
- 'wait' -- This attribute specifies the longest time (in seconds) that the connection manager is allowed to wait before responding to any request during the session. This enables the client to limit the delay before it discovers any network failure, and to prevent its HTTP/TCP connection from expiring due to inactivity.
(...)
7.2 Session Creation Response
(...)
- '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).
(...)
I'm seeing the following behavior with Openfire where a session was established with these attributes in the response:
secure="true" requests="2" inactivity="30" polling="5" wait="59" hold="1" ack="3554851751" maxpause="300" ver="1.6"
Generally speaking, subsequent request seem to follow each-other immediately. Occasionally though, the response to a request isn't followed by an immediate new request (I don't know why). Instead, it takes, in this example, between 58 and 60 seconds for a new request to be made, as shown in this screenshot:
(note the green line in the red box being interrupted).
When the client eventually does create a new request, the server rejects it, as the inactivity period has passed.
It seems that the client is using the 'wait' period to generate a new request (why it didn't do so immediately might be a topic for a different issue). Instead, it probably should have used the 'inactivity' period.
@jcbrand: Have you seen this ticket?
@Neustradamus I was already pinged by @guusdk, there's no need for you to come afterwards and ping me again.