[Standards] throttling

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Fri Feb 11 22:40:05 UTC 2011

On Friday 11 February 2011 14:04:59 Matthew Wild wrote:
> My opinion on this is that we don't need application-layer throttling
> mechanisms. If a server wants to punish a peer, it can simply stop
> reading from the connection for a while. The peer doesn't have to know
> about this (such a notification MAY be useful for UI purposes, but I
> personally doubt it).

The trouble is that throttling and keepalive pings don't play well together.  
It is easy to imagine a client today that uses XEP-0199 pings to the server 
every minute, but then gets throttled by the server for over a minute.  The 
result is that sending too fast means you get disconnected.  This is pretty 
terrible if there's no way to know what counts as "too fast".

The original XEP-0198 required the server to respond to pings at all times, 
even when a client was being throttled.  This approach was abandoned for being 
impractical, but at the time it was the only way I could think of making 
everything work the way we want.

The revised approach in XEP-0198 allows servers to throttle the traditional 
way by stopping socket reads, provided that it periodically sends throttle 
messages to the client.  Basically these are one-way pongs, under the 
assumption that the client would probably be sending pings if it was able to.

All of that said, I wonder now if we can replace the throttle messages with 
whitespace keepalives.  So servers stop reading data from the socket, but 
still continue to send whitespace to the client on a regular interval.  
Clients should not time out a connection if it continues to receive data from 
the server.  Maybe that's all we need?


More information about the Standards mailing list