FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

On Fri, 27 Oct 2017, LacaK wrote:

> Same behavior also on Windows (current master) and on Linux (Ubuntu with 
> installed libsybdb5 package) Once network cable is unpluged loop freezes 
> and FAIL is not returned from dbnextrow()

> So I think, that it is reproducible case ...

Some systems depending on configuration when physical link is lost actively 
close logical interface and associated sockets.  These systems should 
return an error right away.  Some do nothing.

The difference you are seeing in your testing after waiting longer than a 
certain period is a result of server side of the session giving up and 
shutting down the TCP session.  Under your test condition the client is 
likely to have no idea this has occurred.  All it knows is more data may or 
may not arrive at some undetermined point in the future.  With TCP a 
client can find out in one of three ways:

1. Something is transmitted over TCP session such as request for more data 
or app layer keep-alive - at which point lack of connectivity is detected 
when transmission timeout expires.

2. A TCP layer keep-alive fires off and time outs.  On windows the default 
keep-alive interval is 2 hours.

3. Local application timeout such as a configured query timeout?

Otherwise I would expect the application to sit and wait forever for data 
that may never arrive over a server/network/socket that may no longer 
exist.  On Windows you are likely looking at 2 hours maximum wait before 
anything times out.

On Windows try waiting 2 hours, using a query timeout or sysinternals 
tcpview/process explorer to force close socket of database session from 
client process and see if you get an error.

regards,
Peter