if not ClientChannel.Connected then exit;
try
if ClientChannel.IOHandler.InputBufferIsEmpty then
begin
ClientChannel.IOHandler.CheckForDataOnSource(10);
Note that
Connected() performs a read operation internally (with a 0-second timeout), so calling
CheckForDataOnSource() immediately afterwards is a bit redundant. The InputBuffer will either be empty or not after
Connected() returns.
But if the internet connection just ends (i turn off the wifi connection to test), the application hangs in this procedure.
Makes sense, since an
abnormal loss of connection is not reported by the OS in a timely manner (it can take minutes/hours!), so until the OS
eventually times out internally and invalidates the connection,
Connected() will happily continue to return True, and
ReadLn() will happily wait for new data up to the specified timeout (via its optional
ATimeout parameter, or the IOHandler's
ReadTimeout property - neither of which you appear to be using).
How i could prevent this?
Just because
Connected()/
CheckForDataOnSource() report that data has arrived does not guarantee that a
complete line is available in the
InputBuffer. You should assign a non-infinite timeout to the
ReadLn() operation itself.
You might also consider enabling TCP-level keepalives (via
ClientChannel.Socket.Binding.SetKeepAliveValues(), for instance) so that the OS can timeout internally sooner rather than later if the connection is lost unexpectedly.