TCP connect in Non Blocking Mode - Unix

This is a discussion on TCP connect in Non Blocking Mode - Unix ; On Apr 29, 1:38 pm, Alan McKenney wrote: > This leaves unanswered the question: why does checking > only for writeability (assuming that the OP did this > -- the code is a bit sketchy) not work for the OP? ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: TCP connect in Non Blocking Mode

  1. Re: TCP connect in Non Blocking Mode

    On Apr 29, 1:38 pm, Alan McKenney wrote:

    > This leaves unanswered the question: why does checking
    > only for writeability (assuming that the OP did this
    > -- the code is a bit sketchy) not work for the OP?


    The OP had a bug in his code. If you look at his post closely, he
    points out that he fixed the bug, and now his code works.

    > I'm pushing this point because I want to do more
    > or less the same thing the OP is trying to do.
    > Right now, the code I have (more or less copied
    > from its predecessor) doesn't do select() at all.
    > It just does connect() and sleep(1) in a loop
    > until connect() returns success or failure of
    > the connection. Since the old code uses select()
    > everywhere else, I can't help wondering if there
    > is a reason it doesn't use it here.


    Probably cargo cult programming.

    > I would like to improve the code by using
    > something like select(), but the Solaris "man"
    > pages are not clear as to what Sun thinks
    > are read/write/exception events, especially
    > with sockets.


    I have code that uses 'poll' to wait for asynchronous connections to
    complete. It usually uses more sophisticated I/O mechanisms on
    Solaris, but we test with those both enabled and disabled, and we've
    never had a problem. We only check writability for pending
    asynchronous connections.

    > For what it's worth, Stevens (_Unix_Network_Programming_,
    > vol. 1) recommends checking for both readability and
    > writability; he seems to be considered An
    > Authority, so I'm assuming this is based on
    > experience with a wide variety of implementations.


    That is how cargo cult programming spreads. You see someone else do
    it, don't understand why, and so you do it too. (This is not to say
    that Stevens is wrong.)

    DS

  2. Re: TCP connect in Non Blocking Mode

    On Apr 30, 1:00 pm, David Schwartz wrote:
    > On Apr 29, 1:38 pm, Alan McKenney wrote:
    >
    > > This leaves unanswered the question: why does checking
    > > only for writeability (assuming that the OP did this
    > > -- the code is a bit sketchy) not work for the OP?

    >
    > The OP had a bug in his code. If you look at his post closely, he
    > points out that he fixed the bug, and now his code works.
    >
    > > I'm pushing this point because I want to do more
    > > or less the same thing the OP is trying to do.
    > > Right now, the code I have (more or less copied
    > > from its predecessor) doesn't do select() at all.
    > > It just does connect() and sleep(1) in a loop
    > > until connect() returns success or failure of
    > > the connection. Since the old code uses select()
    > > everywhere else, I can't help wondering if there
    > > is a reason it doesn't use it here.

    >
    > Probably cargo cult programming.
    >
    > > I would like to improve the code by using
    > > something like select(), but the Solaris "man"
    > > pages are not clear as to what Sun thinks
    > > are read/write/exception events, especially
    > > with sockets.

    >
    > I have code that uses 'poll' to wait for asynchronous connections to
    > complete. It usually uses more sophisticated I/O mechanisms on
    > Solaris, but we test with those both enabled and disabled, and we've
    > never had a problem. We only check writability for pending
    > asynchronous connections.
    >
    > > For what it's worth, Stevens (_Unix_Network_Programming_,
    > > vol. 1) recommends checking for both readability and
    > > writability; he seems to be considered An
    > > Authority, so I'm assuming this is based on
    > > experience with a wide variety of implementations.

    >
    > That is how cargo cult programming spreads. You see someone else do
    > it, don't understand why, and so you do it too. (This is not to say
    > that Stevens is wrong.)
    >
    > DS


    Setting the select for check for readability of sock descriptor didn't
    help in my case. I now check for getsockopt(SO_ERROR) to determine the
    status as shown below:

    //
    if(getsockopt(sd, SOL_SOCKET, SO_ERROR, (int*)&l_sock_optval,
    (socklen_t*)&l_sock_optval_len) !=0)
    {
    return 0;
    }

    if(l_sock_optval == 0)
    {
    //connection sucess
    break;
    }
    else if(l_sock_optval == ECONNREFUSED)
    {
    //connection refused. This condition comes true on
    receiving RST from server.
    return 0;
    }

    Thanks,
    Prabhu. S

  3. Re: TCP connect in Non Blocking Mode

    On Apr 28, 3:24 pm, Alex Fraser wrote:

    > > The reason he wasn't detecting a connection error was already fixed
    > > when he posted this thread. That's why he says, in the first post,
    > > that it's now working.

    >
    > Huh?


    Sorry, I'm confusing the two posts from the same person about the same
    problem. I believe the OP's problem has long been resolved, it was due
    to a combination of errors, primarily failing to abort from the
    'select' loop on an error.

    DS

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2