Changing the non-blocking connect() timeout (Linux)
Author
I've run into what seems to be a very common problem with no working solutions.
Right now I'm doing a non-blocking connect() and using select() to handle my sockets. As usual my sockets will end up in the except set if the connect() times out and fails.
The problem is that the default timeout happens to be 75 seconds. This is way too long for my application.
I've tried setting SO_SNDTIMEO as someone suggested, nothing. SO_RCVTIMEO, nothing. Neither appear to have any effect. Note that I am using Gentoo Linux, *not* Windows. Please do not post Windows solutions, I have enough of those already. [wink]
Thanks in advance.
Set an alarm() for whatever timeout you wish, and close the socket if it's reached before getting a connection.
Author
Surely there's a way to modify the actual timeout value other than that, isn't there? What if systems have a default timeout lower than what I want to set it to?
I've heard dropping connections this way isn't a very good idea. Isn't there a way to set the timeout (much like the blocking timeout) so it handles it at the TCP/IP level?
I've heard dropping connections this way isn't a very good idea. Isn't there a way to set the timeout (much like the blocking timeout) so it handles it at the TCP/IP level?
How are you doing the non-blocking connect? With fcntl?
A working solution might be to simply spawn the connect() into its own thread so the rest of your app can go about its business.
A working solution might be to simply spawn the connect() into its own thread so the rest of your app can go about its business.
There's no well-defined way of tweaking the various TCP parameters; the specifics depend on each TCP stack implementation. On Linux, I'd expect the parameters to live in /proc/sys/net/ipv4/ somewhere, if they are available. Warning, though: you need root to change them, and the changes are global.
Seeing as you're doing a nonblocking connect, you can simply wait until you're bored waiting for it, then cancel the connect (typically by closing the socket).
Presumably you've got some sort of game loop running around processing other time-based events, so adding a new one should not be tricky.
Mark
Presumably you've got some sort of game loop running around processing other time-based events, so adding a new one should not be tricky.
Mark
Author
Alright, I guess I can live with timing them myself. It sucks that there's no standard way to do this. [headshake]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement