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
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
> THtt
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 pa
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 THttp
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, unplug
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
