- From: Markku Savela <msa@msa.tte.vtt.fi>
- Date: Thu, 12 Sep 1996 13:52:43 +0300 (EET DST)
- To: www-lib@w3.org
This has been discussed before, but has there been any solution presented? Currently, you can use HTEventrg_registerTimeout(tp, request, tbcf, always) to get a callback when any(?) of the sockets times out. As coded currently, there is no way to recover from stuck connection for specific object. Unless the socket in question actually returns some error, the library will wait forever. If you put a timeout, it does get called, but there is nothing to do, as there is no way to identify the the stuck socket in the callback, and if you return HT_OK, the event loop just continues as nothing had happened. And, if you return anything else, the event loop terminates. What is needed When timeout on some socket/request occurs, (1) application needs to know which request it was, and (2) application must have a way to abort the request (HTRequest_KILL?). In this sense, the 'request' parameter to registerTimeout is totally misleading and useless. The callback function should get the request of the timed out socket. -- I suppose, for interactive browser this is not a problem, as the user can just manually cancel everything, if he/she gets bored at waiting for inlines, but for a proxy/server/robot this wont work. In such environment a way to give up stalled transfers without terminating all other parallel working transfers, is required. Could the return from the timeout_handler somehow be used to force abort of the socket connection? Thus instead of the two alternatives now == HT_OK continue as nothing happened (timeout ignored) != HT_OK exit event loop (abort everything) we should have a third alternative return == HT_??? close the sockets and have normal termination handlers deal with them? Of course, as currently implemented, the use of timeout value in select is wrong. In a busy server environment the timeout may never occur, as there are always things happening on other sockets. To solve this, the event loop should remember for each socket when it last had some action, and if "(current_time - last_action_time) > timeout", then one should call the timeout_handler for this socket/request. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
Received on Thursday, 12 September 1996 06:53:44 UTC