[Standards-JIG] Re: Council decision on "Stanza Acking" proposal

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Tue Mar 29 20:02:46 UTC 2005


On Monday 28 March 2005 04:42 am, Matthias Wimmer wrote:
> What I am missing are time limites ...

I'd say any large number would suffice.  5 minutes maybe?  Something large 
enough that it would be unreasonable to not have responded by then.

> maybe not fixed ones but it could 
> be negotiated ... if the client is allowed to defer acking a stanza for
> as long as it wants ... does the server have to cache all stanzas sent
> to the client while the client decides not to answer? I think the server
> has to be able to limit the time a client is allowed to not acking a
> stanza and if it does not get back an ACK within this interval, it
> should be allowed to consider the connection broken and drop the
> connection.

I didn't intend for connections to be dropped if they didn't ack in time.  Say 
that there is a lot of network lag and a large stack of stanza build-up.  I 
suggest resetting your "drop" timeout whenever there is network activity at 
all from the client, not whether or not a stanza has been ack'd.  Drop the 
client if there is 5 minutes of no network activity.

> Same for the ping ... it is said that the client must send the pong
> immediatelly. How many seconds is immediatelly? After which amout of
> time should the server consider the connection to be broken?

Again, 5 minutes.  And again, only with lack of network activity.  If the 
client is blasting you a large amount of stanzas, and then you ping it, keep 
in mind that the pong might come a bit later.  As long as there is network 
activity from the client, you shouldn't drop it.

> Sure this should not be a fixed amount of time as different deployments
> might need different times, but I think there should be advices for
> normal cases and the server should be able to specify limits at least
> for the first case.

5 minutes, 10 minutes, 20 minutes, etc.  We didn't have much control over the 
TCP timeout, but we accept that it is probably reasonably large.  Pick 
something reasonably large for your server, and all will be well.

-Justin



More information about the Standards mailing list