timeout on connect
in [Unix Programming]
|
From: Ian Collins on 10 Mar 2010 18:37 On 03/11/10 12:35 PM, Nicolas George wrote: > Ian Collins wrote in message<7vqlkgF2n1U2(a)mid.individual.net>: >> Otherwise, >> set the socket blocking and carry on. > > Call getsockopt(SO_ERROR) to see if connect succeeded. Why? If the socket is writeable, it is connected. -- Ian Collins
From: cerr on 10 Mar 2010 18:58 On Mar 10, 3:37 pm, Ian Collins <ian-n...(a)hotmail.com> wrote: > On 03/11/10 12:35 PM, Nicolas George wrote: > > > Ian Collins wrote in message<7vqlkgF2n...(a)mid.individual.net>: > >> Otherwise, > >> set the socket blocking and carry on. > > > Call getsockopt(SO_ERROR) to see if connect succeeded. > > Why? If the socket is writeable, it is connected. Right so i do this before send: tv.tv_sec=1; FD_ZERO(&wset); FD_SET(PIDlist[pid].Socket, &wset); int ret = select(PIDlist[pid].Socket + 1, NULL, &wset, NULL, &tv); if (!ret) Timeout(); else send(...); That seems to work quite well but can't verify right now cause i do not have a server to connect to at the moment....:( Ron
From: Rick Jones on 10 Mar 2010 19:04 cerr <ron.eggler(a)gmail.com> wrote: > Right so i do this before send: > tv.tv_sec=1; > FD_ZERO(&wset); > FD_SET(PIDlist[pid].Socket, &wset); > int ret = select(PIDlist[pid].Socket + 1, NULL, &wset, NULL, &tv); > if (!ret) > Timeout(); > else > send(...); > That seems to work quite well but can't verify right now cause i do > not have a server to connect to at the moment....:( Well, if you have a system with an inetd running, you could enable the "discard" service - perhaps as easily as editing a /etc/inetd.conf or /etc/xinetd.conf file and restarting the inetd. Then, poof, you have a server running to which you can connect. It will take whatever you send it and simply discard it - hence the name. There is also "echo" which sends your bytes back to you, and "chargen" which sends you a stream of bytes. rick jones -- the road to hell is paved with business decisions... these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Ian Collins on 10 Mar 2010 19:23 On 03/11/10 12:58 PM, cerr wrote: > > That seems to work quite well but can't verify right now cause i do > not have a server to connect to at the moment....:( VirtualBox is your friend! -- Ian Collins
From: Ersek, Laszlo on 11 Mar 2010 09:42
In article <0f59527d-5d20-4440-b0ee-f7958d77c786(a)t34g2000prm.googlegroups.com>, cerr <ron.eggler(a)gmail.com> writes: > I have an application that tries to establish a TCP connection to a > server usingf connect. If the server does not exist it seems as if it > tries foirever before it eventually times out. How can i reduce this > timeout? 1) Use the non-blocking way others have suggested. 2) Your situation may allow for keeping everything blocking and interrupting connect() with SIGALRM. You would set up an empty signal handler for SIGALRM with sigaction(), or a handler which only sets a volatile sig_atomic_t variable with static storage duration to a different value than initialized to, then register an alarm with alarm(), ualarm() or setitimer(ITIMER_REAL), then issue a blocking connect(). If connect() returns with -1/EINTR (and the sig_atomic_t flag changed), then the connection timed out. If you catch no other signals, or all other caught signals are blocked during connect(), then -1/EINTR is sufficient, and the sig_atomic_t flag is superfluous (nothing else than SIGALRM can interrupt connect()). 3) On Linux, see "man 7 tcp" and search for "tcp_syn_retries". Cheers, lacos |