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