|Subject:||Re: Having relibility problems with tidpop3 and tidsmtp|
|Posted by:||Remy Lebeau (TeamB) (firstname.lastname@example.org)|
|Date:||Mon, 6 Mar 2006|
"arthur hoornweg" <email@example.com> wrote in message
> Sometimes, when I check upon our mailserver on monday
> mornings, I find it has been in this condition since the saturday
> before. Our DSL connection is automatically closed once
> every 24 hours by the internet provider (t-online in Germany).
> So why doesn't the readtimeout kick in?
The OS, not Indy, handles the actual timeout. For your code to be hung for
so long, Indy passed the timeout value to the OS and then the OS did not
tell Indy when the timeout occured, so Indy was stuck waiting for the OS's
reply. That can typically only happen if the connection is not being closed
gracefully by the ISP, such that the underlying socket stack inside the OS
(WinSock on Windows, libc on Linux, etc) has to time itself out internally
before it can recognize a lost connection. Unfortunately, the OS's internal
tiemouts tend to fairly large, and cannot be configured programmably. But I
have not heard of it taking 2 days for an OS to detect a lost connection,
but it is possible.
> If the transmission is interrupted for any reason, the readtimeout
> should kick in sooner or later, shouldn't it?
Only if the OS detects the lost connection so that the socket API begins
reporting errors on that socket. Without those errors, there is no way for
Indy do know what is happening.
Having relibility problems with tidpop3 and tidsmtp posted by arthur hoornweg on Sun, 05 Mar 2006