Paul J. Lucas <paul <at> lucasmail.org> writes: > Suppose I have a service that takes some time to compute the > response to. Further suppose that a client connects but then > disconnects prematurely for whatever reason either before I start or > while I am returning a response. Is there any way to know if the > client is really still there and connected?
Getting away from the behavior of TCP and socket APIs, and getting back to the other part of your question could provide more HTTP-ish, Restful solutions... Since in the case the concern is getting the result of a long-running computation, HTTP offers some choices above the level of keeping a client connected. e.g. "202 Accepted" is a way the server can tell the client the request has been accepted but is not yet complete. The response body should include a URL or some clear indication of how the client can subsequently get the result, and/or status as the job makes progress. Another choice might be to return a redirection status code, like "303 See Other" which also should include a URL for the client to GET the response. This implies (to me anyway) that the result is expected to be complete whenever the client does the subsequent GET. Otherwise the 202 seems a more appropriate way to tell the client the result may or may not be ready with a subsequent GET. In either of these cases the client or the server should be able to fail repeatedly in between POSTs and GETs without upsetting the ultimate behavior of the exchange. I think the general lesson is don't try to solve application-layer problems (e.g. HTTP) in the transport layer (e.g. TCP). Trying to keep a socket open, and detect it, in a stateless protocol is an indication of this. Use the application protocol's features, e.g. asynchronous request processing with 202's. -Patrick
