- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 13 Feb 2013 17:39:22 +1300
- To: ietf-http-wg@w3.org
On 13/02/2013 7:18 a.m., Roberto Peon wrote: > > The problem that we have here is that the TCP API isn't sufficiently > rich to allow us to do the right thing (e.g. read bytes without > allowing the sender to send more). As a result, we have to have > another level of flow control which we'd otherwise be able to do > without. Unfortunately, per priority TCP connections don't work well > for large loadbalancers where each of these connections will likely be > terminating at a different place. This would create a difficult > synchronization problem server side, full of races and complexity, and > likely quite a bit worse in complexity than getting flow control > working well. As opposed to HTTP/1.x where each request may have its own TCP connection, end up at a different endpoint, and faces identical situation? Sure this is not a solution to *that* problem, but nothing will. 1) The load balancers very existence purpose is to *create* that problem. 2) HTTP is meant to be stateless remember, so no request depends on any other for semantic handling. These high priority and low-priority requests you speak of. 3) the frames where statefulness and priority actually matters are per-hop control frames. Which the endpoint needing to send is perfectly capable of injecting for delivery between any other frames it may have queued. Regardless of how or when any other party along the channel believes they should be delivered. So I agree with Nico on this one. Separate TCP connections *are* an option. It just has to be made clear in the spec how to identify them at the server and how it is expected to prioritize those connections from any other more important ones it may be handling in parallel. Any endpoint screwups caused by load balancing as a result of handling two *independent* requests via different pathways is the responsibility of the server admin, site author, or network admins to sort out - not the HTTP protocol. Amos
Received on Wednesday, 13 February 2013 04:39:55 UTC