How to set a connect() timeout (?)
tundra at tundraware.com
Thu Aug 13 16:58:56 UTC 2020
On 8/13/20 5:11 AM, Ronald F. Guilmette wrote:
> This is driving me bonkers and I feel like I'm having deja vu all over again.
> (In other words I think I may have asked about this before in the very distant
> Setting a programmed time limit for the connect() system call seems to be a
> common thing that many people, not just myself, often want to do. It is not
> at all clear if there is or isn't a simple way to do that, e.g. one that
> doesn't involve calling select() or poll() or something like that.
> On FreeBSD, there is a system-wide sysctl variable that sets the system-wide default
> connect timeout. It's called net.inet.tcp.keepinit. But I really do want to be
> able to programatically set the connect timeout for individual (outbound) sockets.
> setsockopt() provides the SO_SNDTIMEO and SO_RCVTIMEO options which allow setting
> of timeouts on individual sockets for writing and reading respectively, but it is
> not immediately apparent, e.g. from the relevant man page, that either of these
> setsockopt() options will have any effect on the connect() timeout period.
> In online sources there is some suggestion that one or the other of these two
> setsockopt() options can be used, at least on Linux, to programatically control
> the per-socket connect timeout period, but I have not tried that on my own Linux
> system so I may be reading too much into what I have been reading.
> I am forced to wonder why, on FreeBSD there is no such thing as an SO_CONTIMEO
> option that can be used with setsockopt() to easily control the connect() timeout
> on a per-socket basis.
> Can anyone explain to me why there isn't such a thing? Seems like rather a glaring
> oversight to me, and a no-brainer (that such a thing really should exist).
I may have this wrong so don't take this a gospel, but as I don't believe timeouts
as you describe them were ever a 1st class thing in the BSD sockets definition.
It is certainly the case that these sort of semantics are typically well implemented
a layer up from the raw socket. For example, timeout management is handled in the Python
socket library, Tornado, and gRPC, all to pretty good effect.
Again, much of this is lost in the bitrot of brain, but this is what I recall anyway.
Tim Daneliuk tundra at tundraware.com
PGP Key: http://www.tundraware.com/PGP/
More information about the freebsd-questions