timeout on connect
in [Unix Programming]
|
From: cerr on 10 Mar 2010 17:37 On Mar 10, 2:27 pm, Nicolas George <nicolas$geo...(a)salle-s.org> wrote: > Rick Jones wrote in message <hn955b$5r...(a)usenet01.boi.hp.com>: > > Well, the socket is non-blocking now - so if you were counting say on > > He can put it back to blocking when the socket is connected. But how would I know if it's set to not-blocking? > > a send() call with 65536 bytes to not complete before it finished > > getting the 65536th byte into the stack you will have issues - ie a > > send() call can complete before all the bytes go into the stack. > > That is not necessarily true with a blocking socket either. If the socket > can take 32k without blocking, then a non-blocking socket will accept 32k > (the return value of send will be 32k), and then fail with EAGAIN. A > blocking can possibly block until all 64k are accepted, or just accept 32k > on the first call, and then block until it can accept some more. > > All low-level read and writes must be wrapped in loops to ensure that all > the data is read or written. > > > IIRC a connec() return on a non-blocking socket doesn't mean the > > connect() has actually completed - you cannot just turn around and > > start writing to the socket (IIRC) but need to wait in a select() or > > poll() - with a timeout of your own chosing - until the socket > > becomes, well, writable I guess, > > Yes, writable. > > > which will indicate the connection is > > actually established. > > Or failed. The status can be retrieved using setsockopt(SO_ERROR). Won't select() return me success (>0)or fail (<=0)? from the man page: (that is, the total number of bits that are set in readfds, writefds, exceptfds) which may be zero if the timeout expires before anything interesting happens.
From: Rick Jones on 10 Mar 2010 17:39 Nicolas George <nicolas$george(a)salle-s.org> wrote: > That is not necessarily true with a blocking socket either. If the > socket can take 32k without blocking, then a non-blocking socket > will accept 32k (the return value of send will be 32k), and then > fail with EAGAIN. A blocking can possibly block until all 64k are > accepted, or just accept 32k on the first call, and then block until > it can accept some more. I'm not sure I'm parsing your last sentence there - are you saying that a 64K send() call against a blocking socket can return before all 64K of data are in the transport? > All low-level read and writes must be wrapped in loops to ensure > that all the data is read or written. 100% agreement on read() calls - one can have read/recv return but a single byte on a blocking call asking for N bytes, but... Where can a blocking socket return something other than an error or the length of bytes requested to send? > > which will indicate the connection is actually established. > Or failed. The status can be retrieved using setsockopt(SO_ERROR). True, it could have failed. Wouldn't that be getsockopt(SO_ERROR)? I've always been under the impression that one could just go ahead and make their desired "real" (as it were) socket call after the select() and get the error return that way. rick jones -- a wide gulf separates "what if" from "if only" 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 17:39 On 03/11/10 11:37 AM, cerr wrote: > On Mar 10, 2:27 pm, Nicolas George<nicolas$geo...(a)salle-s.org> wrote: >> Rick Jones wrote in message<hn955b$5r...(a)usenet01.boi.hp.com>: >>> Well, the socket is non-blocking now - so if you were counting say on >> >> He can put it back to blocking when the socket is connected. > > But how would I know if it's set to not-blocking? Set the socket non-blocking. Call connect. Call select of poll and check the return to see if the socket is writeable. If not, there's been a timeout. Otherwise, set the socket blocking and carry on. -- Ian Collins
From: Nicolas George on 10 Mar 2010 18:34 Rick Jones wrote in message <hn972p$68j$1(a)usenet01.boi.hp.com>: > I'm not sure I'm parsing your last sentence there - are you saying > that a 64K send() call against a blocking socket can return before all > 64K of data are in the transport? I thought that write/send were allowed to behave like read: block if necessary, but only the minimum amount to do something. But I just checked and it seems I was mistaken: while read will return as soon as there is data available, even if it is less than requested, write is supposed to block until all is sent. But write can still be interrupted by a signal and return less than the data size. > Wouldn't that be getsockopt(SO_ERROR)? Yes, sorry.
From: Nicolas George on 10 Mar 2010 18:35
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. |