Re: network timeouts when there's no connected network

On 6/8/25 5:28 PM, Eben Bruyns (as eben at sdk dot co dot nz) wrote:
> Hi,
>
> I have a situation where I need to have a very short timeout on socket 
> connections if the network is not available. Currently I'm using 
> dexador (same happens with Drakma), to connect to a web service. The 
> timeouts does not seem to affect the socket mechanisms, from what I 
> can gather this is due to dns resolution, and apparently it's in the 
> comm package.
>
> So I guess the question is what's the usual work around that should be 
> used in this case? I really need a fail fast mechanism if the network 
> is down in this use case.
>
> I guess my current thinking is that I might have to write a network 
> detection system to put the system in "offline mode" if there's no 
> network and check periodically if the network is back up? Seems 
> suboptimal, thought I'd ask the veterans about this one.
>
> Regards,
>
> Eben Bruyns


An "offline" state to cheaply avoid attempting to do network things 
makes sense, though it is always a good idea to provide a manual way to 
control that and likewise to enable/disable any automatic behavior.   
Persistent config option storage to support that is a good idea, so the 
user is able to turn off and otherwise control the brilliant ideas.

Using a DNS lookup to establish network up/down is a relatively bad 
idea.  Sometimes there is no dns available, or the dns is occuring via 
/etc/hosts- or maybe the connection fail issue is elsewhere on the 
network so DNS resolution does not always equate to the remote system 
being accessible and ready.

Short timeouts for network connections are not very desirable- same as 
long timeouts.    I'm assuming by "short" you're talking about something 
like less than 1 second.   A short timeout of 3 to 4 is probably more 
resilient in challenging network conditions. Long timeouts are annoying 
(eg 30 secs) especially if its not possible to cancel them.

It is very helpful if your software can log the network operations it is 
attempting- perhaps through a verbose options- so its possible to 
distinguish DNS issues from connection issues, reporting actual error 
codes is also helpful to the user. Timestamping log events such as 
connection attempt and then its success is helpful too; then a quick 
connection vs one that takes seconds to complete can be more clearly 
distinguished.