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? -Justin
