On 18/06/2009, at 3:10 AM, Peter Saint-Andre wrote:
3. A request header to determine timeouts. 4. A request header to determine the longest acceptable polling interval.
I've been thinking about these a bit.One thing that could be done would be to have each hop add an indication of how long it's able to keep a connection open to the request; e.g.,
LongPoll-Timeout: 30, 60, 0 However, there are a few downsides here:* It relies on every hop adding its information, otherwise the numbers are misleading * It actually requires two numbers for each intermediary, since they can treat client-side and server-side connections independently (and often do, in terms of timeouts) * The information is only available to the server; the client only knows its own preferences, and intermediaries only know preferences in the direction of their clients.
I'm starting to think that a reasonable alternative would be to simply have the client insert a flag in the request (e.g., a header) that indicates that it's interested in long-polling, without timeout or interval information. This way, intermediary implementations as well as servers can use that information to adjust their use of resources accordingly.
Another approach would be to run some sort of discovery protocol before polling begins, so that the client (and potentially intermediaries) can figure out timeouts and appropriate polling intervals beforehand. I'm inclined to think that this would be too complex for practical use, however; it would require significant implementation overhead (especially in intermediaries) and wouldn't be robust (e.g., in the face of more complex proxy topologies).
Thoughts? -- Mark Nottingham http://www.mnot.net/
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.