On 07-03-2011 06:31, Arno Garrels wrote:
That's sounds like a bug. I would expect that THttpCli is reset to
default values after that error?
I don't see any reference to 10053 in any of the ICS code, so I
suppose this situation is not being handled internally by the THttpCli.
Because the
On 07-03-2011 06:31, Arno Garrels wrote:
TWSocket property KeepAliveOnOff may be used to setup winsock to send
keep-alive packets in the background in order to detect such brocken
connections, however that's not reliable since both peers must support
it and routers have to route the keep-alive
RTT wrote:
On 07-03-2011 06:31, Arno Garrels wrote:
That's sounds like a bug. I would expect that THttpCli is reset to
default values after that error?
I don't see any reference to 10053 in any of the ICS code, so I
suppose this situation is not being handled internally by the
THttpCli.
RTT wrote:
On 07-03-2011 06:31, Arno Garrels wrote:
TWSocket property KeepAliveOnOff may be used to setup winsock to send
keep-alive packets in the background in order to detect such brocken
connections, however that's not reliable since both peers must
support it and routers have to route
Isn't the CtrlSocket.State reliable to know if a connection is still on?
I'm trying to reuse an THttpCli, but I'm getting 10053 errors if a
persistent connection is idle for some time, I suppose the server
keepalive timeout.
The ICS THttpCli code check this CtrlSocket.State property, to try to
RTT wrote:
Isn't the CtrlSocket.State reliable to know if a connection is still
on?
No it isn't. Whether or not a connection is still alive can only be
known if either the FD_CLOSE notification from winsock is received
or an attempt to send or receive failed or succeeded.
For example,
