On 12 February 2011 19:56, Rene Treffer <[email protected]> wrote: > On 02/11/2011 11:40 PM, Justin Karneges wrote: >> 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". >> > > This looks suspicious. If a server drops / delays pings I'd say it's a > server bug, not a client not implementing a XEP. You should seriously > think about handling pings differently if you feel like dropping them. >
A server can choose to spend CPU time and RAM processing stanzas from the client, or it can choose to ignore that client for a while. If the client is flooding the server with stanzas, it only seems right it should be throttled, no? If it's being throttled, we have no way of knowing if a ping is in the socket buffer unless we spend CPU time parsing, etc. I'm not convinced that we need a solution for this (I'm not sure if in the real world, a server would actually stop reading from a client for 60s or more). However if consensus is that this is something we need to fix, I think Justin's on the right track and I wouldn't oppose standardising "whacks" (at last!). Regards, Matthew
