select() on non-blocking socket - TCP-IP

This is a discussion on select() on non-blocking socket - TCP-IP ; Hi All, I've created a socket and set it for non-blocking operation. Later, I'm trying to use connect() system call to connect to an invalid address and port number (i.e there no listening server running on this address). The connect() ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: select() on non-blocking socket

  1. select() on non-blocking socket

    Hi All,

    I've created a socket and set it for non-blocking operation. Later,
    I'm trying to use connect() system call to connect to an invalid
    address and port number (i.e there no listening server running on this
    address). The connect() immediately returned by setting errno to
    EINPROGRESS, which is very much expected. After that, I kept this
    socket into write and read fd set and given it to select() call with
    INFINITE time duration. But I'm surprised to see that, both read and
    write fd triggered for this socket fd. I'm trying this experiment in
    Linux 2.4.21.

    But in Solaris 10, the select() was blocking forever as expected.

    Can someone help me out in this? any hint on this would be highly
    appreciated.


  2. Re: select() on non-blocking socket

    In article <1187361805.211691.183120@x40g2000prg.googlegroups. com>,
    soj wrote:

    > Hi All,
    >
    > I've created a socket and set it for non-blocking operation. Later,
    > I'm trying to use connect() system call to connect to an invalid
    > address and port number (i.e there no listening server running on this
    > address). The connect() immediately returned by setting errno to
    > EINPROGRESS, which is very much expected. After that, I kept this
    > socket into write and read fd set and given it to select() call with
    > INFINITE time duration. But I'm surprised to see that, both read and
    > write fd triggered for this socket fd. I'm trying this experiment in
    > Linux 2.4.21.
    >
    > But in Solaris 10, the select() was blocking forever as expected.
    >
    > Can someone help me out in this? any hint on this would be highly
    > appreciated.


    Post your code, I suspect you have a bug in it. This kind of bug in
    Linux could hardly go unnoticed and unfixed.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: select() on non-blocking socket

    In article , barmar@alum.mit.edu (Barry Margolin) writes:
    | In article <1187361805.211691.183120@x40g2000prg.googlegroups. com>,
    | soj wrote:
    |
    | > Hi All,
    | >
    | > I've created a socket and set it for non-blocking operation. Later,
    | > I'm trying to use connect() system call to connect to an invalid
    | > address and port number (i.e there no listening server running on this
    | > address). The connect() immediately returned by setting errno to
    | > EINPROGRESS, which is very much expected. After that, I kept this
    | > socket into write and read fd set and given it to select() call with
    | > INFINITE time duration. But I'm surprised to see that, both read and
    | > write fd triggered for this socket fd. I'm trying this experiment in
    | > Linux 2.4.21.
    | >
    | > But in Solaris 10, the select() was blocking forever as expected.
    | >
    | > Can someone help me out in this? any hint on this would be highly
    | > appreciated.
    |
    | Post your code, I suspect you have a bug in it. This kind of bug in
    | Linux could hardly go unnoticed and unfixed.

    Perhaps I'm misreading, but the described Linux behavior appears correct
    to me. Once a socket has an error saved (probably ECONNREFUSED in this
    example) it will be "ready" for read and write as far as select() is
    concerned--at least per the original BSD sockets API. And in fact since
    read and write will not block in this case it isn't an unreasonable
    response. There has been some confusion that exceptfds is for errors,
    but it is for things like OOB data.

    The bug is likely in the Solaris 10 version.

    Dan Lanciani
    ddl@danlan.*com

  4. Re: select() on non-blocking socket

    Hi Barry,

    Please have a look into this code snippets;
    ...............
    ..............
    {
    int sockClient, disable = 1;
    int iNumberOfBytesSnd = 0;
    struct sockaddr_in serverInfo;
    struct timeval *timeoutPtr = 0;
    fd_set read_socks, write_socks;

    sockClient = socket(PF_INET, SOCK_STREAM, 0);
    serverInfo.sin_family = AF_INET;
    serverInfo.sin_port = htons(7944); /* nobody listening on this
    port !!! */
    serverInfo.sin_addr.s_addr = inet_addr("172.25.0.177"); /* This IP
    address is not existing in our subnet */
    memset(&(serverInfo.sin_zero), 0, 8);

    ioctl(sockClient, FIONBIO, &disable); /* for linux 2.4.21 */
    /* fcntl(sockClient, F_SETFL, O_NDELAY); */ /* for Solaris 10 */
    FD_ZERO(&read_socks);
    FD_ZERO(&write_socks);

    FD_SET(sockClient, &read_socks);
    FD_SET(sockClient, &write_socks);

    int iRetValue = connect(sockClient, (struct sockaddr*)&serverInfo,
    sizeof(struct sockaddr));

    if(iRetValue == -1)
    printf("Connection failed : Reason: %d \n", errno);
    else
    printf("connection success on sockfd %d\n", sockClient);

    select(FD_SETSIZE, &read_socks, &write_socks, (fd_set *) 0,
    timeoutPtr);

    if (FD_ISSET(sockClient, &write_socks))
    printf("write fd set \n");

    if (FD_ISSET(sockClient, &read_socks))
    printf("read fd set \n");
    }
    .................
    .................



    On Aug 18, 6:24 am, Barry Margolin wrote:
    > In article <1187361805.211691.183...@x40g2000prg.googlegroups. com>,
    >
    >
    >
    > soj wrote:
    > > Hi All,

    >
    > > I've created a socket and set it for non-blocking operation. Later,
    > > I'm trying to use connect() system call to connect to an invalid
    > > address and port number (i.e there no listening server running on this
    > > address). The connect() immediately returned by setting errno to
    > > EINPROGRESS, which is very much expected. After that, I kept this
    > > socket into write and read fd set and given it to select() call with
    > > INFINITE time duration. But I'm surprised to see that, both read and
    > > write fd triggered for this socket fd. I'm trying this experiment in
    > > Linux 2.4.21.

    >
    > > But in Solaris 10, the select() was blocking forever as expected.

    >
    > > Can someone help me out in this? any hint on this would be highly
    > > appreciated.

    >
    > Post your code, I suspect you have a bug in it. This kind of bug in
    > Linux could hardly go unnoticed and unfixed.
    >
    > --
    > Barry Margolin, bar...@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***






  5. Re: select() on non-blocking socket

    Hi,

    Please have a look into this code snippets;
    ...............
    ..............
    {
    int sockClient, disable = 1;
    int iNumberOfBytesSnd = 0;
    struct sockaddr_in serverInfo;
    struct timeval *timeoutPtr = 0;
    fd_set read_socks, write_socks;

    sockClient = socket(PF_INET, SOCK_STREAM, 0);
    serverInfo.sin_family = AF_INET;
    serverInfo.sin_port = htons(7944); /* nobody listening on this
    port !!! */
    serverInfo.sin_addr.s_addr = inet_addr("172.25.0.177"); /* This IP
    address is not existing in our subnet */
    memset(&(serverInfo.sin_zero), 0, 8);

    ioctl(sockClient, FIONBIO, &disable); /* for linux 2.4.21 */
    /* fcntl(sockClient, F_SETFL, O_NDELAY); */ /* for Solaris 10 */
    FD_ZERO(&read_socks);
    FD_ZERO(&write_socks);

    FD_SET(sockClient, &read_socks);
    FD_SET(sockClient, &write_socks);

    int iRetValue = connect(sockClient, (struct sockaddr*)&serverInfo,
    sizeof(struct sockaddr));

    if(iRetValue == -1)
    printf("Connection failed : Reason: %d \n", errno);
    else
    printf("connection success on sockfd %d\n", sockClient);

    select(FD_SETSIZE, &read_socks, &write_socks, (fd_set *) 0,
    timeoutPtr);

    if (FD_ISSET(sockClient, &write_socks))
    printf("write fd set \n");

    if (FD_ISSET(sockClient, &read_socks))
    printf("read fd set \n");
    }
    .................
    .................



    On Aug 18, 6:24 am, Barry Margolin wrote:
    > In article <1187361805.211691.183...@x40g2000prg.googlegroups. com>,
    >
    >
    >
    > soj wrote:
    > > Hi All,

    >
    > > I've created a socket and set it for non-blocking operation. Later,
    > > I'm trying to use connect() system call to connect to an invalid
    > > address and port number (i.e there no listening server running on this
    > > address). The connect() immediately returned by setting errno to
    > > EINPROGRESS, which is very much expected. After that, I kept this
    > > socket into write and read fd set and given it to select() call with
    > > INFINITE time duration. But I'm surprised to see that, both read and
    > > write fd triggered for this socket fd. I'm trying this experiment in
    > > Linux 2.4.21.

    >
    > > But in Solaris 10, the select() was blocking forever as expected.

    >
    > > Can someone help me out in this? any hint on this would be highly
    > > appreciated.

    >
    > Post your code, I suspect you have a bug in it. This kind of bug in
    > Linux could hardly go unnoticed and unfixed.
    >
    > --
    > Barry Margolin, bar...@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***






  6. Re: select() on non-blocking socket


    Hi Dan,

    As far as my knowledge, there is no data to be written to or read from
    this socket in this case, coz there is no connection established. I'm
    wondering, why would socket need to be set in write fd set (in Linux
    2.4.21 and not in Solaris 10 ) if connection is failed ?

    This raises another question; Let's say the the connect() system call
    on non-blocking socket to an invalid address saved EINPROGRESS to
    errno and returned immediately; and is it possible by any means that
    after some time, connect() would change the errno set to
    ECONNREFUSED ?

    Please have a look at code I posted.

    Thanks & Rgds,
    -soj


  7. Re: select() on non-blocking socket

    In article <1187424291.702075.7120@q4g2000prc.googlegroups.com>, jul.sfx@gmail.com (soj) writes:
    |
    | Hi Dan,
    |
    | As far as my knowledge, there is no data to be written to or read from
    | this socket in this case, coz there is no connection established. I'm
    | wondering, why would socket need to be set in write fd set (in Linux
    | 2.4.21 and not in Solaris 10 ) if connection is failed ?

    Abstractly, select() tells you when you should do a read() or write()
    to move things along. If there is an error you usually want to discover
    it as soon as possible and you will do this when try the read() or write().
    If select() did not behave this way the useless socket would sit on the list
    until you discovered it by some other means. Similarly, select() will tell
    you that a socket whose peer has sent a FIN is ready to read even though
    there is no "data" but merely an end-of-file indication.

    Pedantically, select() tells you whether a read() or write() would block
    on a blocking socket. Neither will block on a socket that failed to connect;
    they will return errors.

    Practically, the existence of a saved error is one of the conditions
    recognized by the soreadable()/sowriteable() macros in the original
    BSD network code that ultimately defined the sockets API. (This is
    not to say that no implementors have changed these semantics either
    through ignorance of because they thought they were making the world
    a better place.)

    | This raises another question; Let's say the the connect() system call
    | on non-blocking socket to an invalid address saved EINPROGRESS to
    | errno and returned immediately; and is it possible by any means that
    | after some time, connect() would change the errno set to
    | ECONNREFUSED ?

    No, the user-level "errno" variable will not change. That would be
    disastrous. But each socket (again, in the original BSD source and
    most faithful sockets implementations) has an internal error variable
    which in your example will likely be set to ECONNREFUSED by the time
    select() tells you to read or write your socket. Typically you can
    retrieve that error with getsockopt()'s SO_ERROR.

    There have been a number of detailed threads on handling asynchronous
    connect()s and select() semantics. You can find some that I participated
    in with a Google Groups search of "Lanciani SO_ERROR".

    Dan Lanciani
    ddl@danlan.*com

  8. Re: select() on non-blocking socket

    In article <1341859@news1.IPSWITCHS.CMM>,
    ddl@danlan.*com (Dan Lanciani) wrote:

    > In article ,
    > barmar@alum.mit.edu (Barry Margolin) writes:
    > | In article <1187361805.211691.183120@x40g2000prg.googlegroups. com>,
    > | soj wrote:
    > |
    > | > Hi All,
    > | >
    > | > I've created a socket and set it for non-blocking operation. Later,
    > | > I'm trying to use connect() system call to connect to an invalid
    > | > address and port number (i.e there no listening server running on this
    > | > address). The connect() immediately returned by setting errno to
    > | > EINPROGRESS, which is very much expected. After that, I kept this
    > | > socket into write and read fd set and given it to select() call with
    > | > INFINITE time duration. But I'm surprised to see that, both read and
    > | > write fd triggered for this socket fd. I'm trying this experiment in
    > | > Linux 2.4.21.
    > | >
    > | > But in Solaris 10, the select() was blocking forever as expected.
    > | >
    > | > Can someone help me out in this? any hint on this would be highly
    > | > appreciated.
    > |
    > | Post your code, I suspect you have a bug in it. This kind of bug in
    > | Linux could hardly go unnoticed and unfixed.
    >
    > Perhaps I'm misreading, but the described Linux behavior appears correct
    > to me. Once a socket has an error saved (probably ECONNREFUSED in this
    > example) it will be "ready" for read and write as far as select() is
    > concerned--at least per the original BSD sockets API.


    What error are you talking about? The only "error" he mentioned was
    EINPROGRESS, which is the normal errno code when a non-blocking socket
    has nothing available to do (maybe you know it better as EWOULDBLOCK).
    It's not really an error, and shouldn't prevent you from using the
    socket again.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  9. Re: select() on non-blocking socket

    In article <1187424291.702075.7120@q4g2000prc.googlegroups.com>,
    soj wrote:

    > Hi Dan,
    >
    > As far as my knowledge, there is no data to be written to or read from
    > this socket in this case, coz there is no connection established. I'm
    > wondering, why would socket need to be set in write fd set (in Linux
    > 2.4.21 and not in Solaris 10 ) if connection is failed ?
    >
    > This raises another question; Let's say the the connect() system call
    > on non-blocking socket to an invalid address saved EINPROGRESS to
    > errno and returned immediately; and is it possible by any means that
    > after some time, connect() would change the errno set to
    > ECONNREFUSED ?


    What do you mean by "invalid address"? If it's an address of a machine
    that's up but not running a server on the port you're connecting to,
    select() should report the socket as writable, and your new call to
    connect() should set errno to ECONNREFUSED (just like it would if you
    were using a blocking socket). But if there's no machine with that
    address, it will eventually set it to ETIMEDOUT.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  10. Re: select() on non-blocking socket

    In article <1187361805.211691.183120@x40g2000prg.googlegroups. com>,
    soj wrote:

    > Hi All,
    >
    > I've created a socket and set it for non-blocking operation. Later,
    > I'm trying to use connect() system call to connect to an invalid
    > address and port number (i.e there no listening server running on this
    > address). The connect() immediately returned by setting errno to
    > EINPROGRESS, which is very much expected. After that, I kept this
    > socket into write and read fd set and given it to select() call with
    > INFINITE time duration. But I'm surprised to see that, both read and
    > write fd triggered for this socket fd. I'm trying this experiment in
    > Linux 2.4.21.
    >
    > But in Solaris 10, the select() was blocking forever as expected.
    >
    > Can someone help me out in this? any hint on this would be highly
    > appreciated.


    I think I understand what's happening.

    Even though you set didn't set a timeout in select(), there's still a
    built-in timeout in connect(); if you were using it in blocking mode, it
    will eventually return with errno set to ETIMEDOUT. Using a
    non-blocking socket and select() doesn't change this -- the TCP stack
    still gives up trying to connect after a few minutes. When this
    happens, select() returns with the socket marked writable, and when you
    call connect() again you'll get that errno.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  11. Re: select() on non-blocking socket

    In article ,
    Barry Margolin wrote:

    >> I've created a socket and set it for non-blocking operation. Later,
    >> I'm trying to use connect() system call to connect to an invalid
    >> address and port number (i.e there no listening server running on this
    >> address). The connect() immediately returned by setting errno to
    >> EINPROGRESS, which is very much expected. After that, I kept this
    >> socket into write and read fd set and given it to select() call with
    >> INFINITE time duration. But I'm surprised to see that, both read and
    >> write fd triggered for this socket fd. I'm trying this experiment in
    >> Linux 2.4.21.
    >>
    >> But in Solaris 10, the select() was blocking forever as expected.


    >I think I understand what's happening.
    >
    >Even though you set didn't set a timeout in select(), there's still a
    >built-in timeout in connect(); if you were using it in blocking mode, it
    >will eventually return with errno set to ETIMEDOUT. Using a
    >non-blocking socket and select() doesn't change this -- the TCP stack
    >still gives up trying to connect after a few minutes. When this
    >happens, select() returns with the socket marked writable, and when you
    >call connect() again you'll get that errno.


    That does not explain the reported difference between Solaris 10 and
    Linux 2.4.21.

    It also overlooks the fact that depending what the other person
    meant by "an invalid address and port number" and depending on the
    local operating system, one should expect other errnor numbers such
    as ECONNREFUSED or even EINVAL.

    My explanation for the observed difference between Solaris 10 and
    Linux is "Mentat STREAMS has (have?) been different." When you
    find such differences, there's no practical point in complaining.
    All you can do is make your code work regardless or refuse to port
    it to the odd platforms. For example, I think answering a second
    connect() or a sendto() with EINVAL simply because the server is
    down or not listen()ing or routing is hosed is wrong, but dealing with
    such wrongness is part of writing protable code.


    Vernon Schryver vjs@rhyolite.com

  12. Re: select() on non-blocking socket

    In article , barmar@alum.mit.edu (Barry Margolin) writes:
    | In article <1341859@news1.IPSWITCHS.CMM>,
    | ddl@danlan.*com (Dan Lanciani) wrote:
    |
    | > In article ,
    | > barmar@alum.mit.edu (Barry Margolin) writes:
    | > | In article <1187361805.211691.183120@x40g2000prg.googlegroups. com>,
    | > | soj wrote:
    | > |
    | > | > Hi All,
    | > | >
    | > | > I've created a socket and set it for non-blocking operation. Later,
    | > | > I'm trying to use connect() system call to connect to an invalid
    | > | > address and port number (i.e there no listening server running on this
    | > | > address). The connect() immediately returned by setting errno to
    | > | > EINPROGRESS, which is very much expected. After that, I kept this
    | > | > socket into write and read fd set and given it to select() call with
    | > | > INFINITE time duration. But I'm surprised to see that, both read and
    | > | > write fd triggered for this socket fd. I'm trying this experiment in
    | > | > Linux 2.4.21.
    | > | >
    | > | > But in Solaris 10, the select() was blocking forever as expected.
    | > | >
    | > | > Can someone help me out in this? any hint on this would be highly
    | > | > appreciated.
    | > |
    | > | Post your code, I suspect you have a bug in it. This kind of bug in
    | > | Linux could hardly go unnoticed and unfixed.
    | >
    | > Perhaps I'm misreading, but the described Linux behavior appears correct
    | > to me. Once a socket has an error saved (probably ECONNREFUSED in this
    | > example) it will be "ready" for read and write as far as select() is
    | > concerned--at least per the original BSD sockets API.
    |
    | What error are you talking about?

    The error that would have resulted from the attempt to connect to a
    port with no listener sometime between the initiation of the asynchronous
    connect() and the return from select(). From his description it appears
    that he is connecting to a live machine with no listener thus my comment
    that the error is _probably_ ECONNREFUSED. This error can usually be
    retrieved with getsockopt()'s SO_ERROR.

    | The only "error" he mentioned was
    | EINPROGRESS, which is the normal errno code when a non-blocking socket
    | has nothing available to do (maybe you know it better as EWOULDBLOCK).

    No, EINPROGRESS is not a general error code for a non-blocking socket
    that has nothing available to do. It is a special case used only with
    asynchronous connect() operations. The confusion with EWOULDBLOCK is
    Winsock stupidity. (Basically, they used EINPROGRESS for a completely
    different purpose and then had to use something else for connect().)

    | It's not really an error, and shouldn't prevent you from using the
    | socket again.

    No, the error that prevents you from using the socket again is the
    final result of the (failed) asynchronous connect(). N.B. some
    implementations will allow you to reuse such a socket after you
    have retrieved the error code with SO_ERROR (which also clears the
    error as a side effect) but this cannot be relied upon if you care
    about portability.

    Dan Lanciani
    ddl@danlan.*com

  13. Re: select() on non-blocking socket

    In article , vjs@calcite.rhyolite.com (Vernon Schryver) writes:

    | It also overlooks the fact that depending what the other person
    | meant by "an invalid address and port number" and depending on the
    | local operating system, one should expect other errnor numbers such
    | as ECONNREFUSED or even EINVAL.

    And of course the code should be prepared to deal with these errors
    both at initial connect() time and later when retrieving the final
    error code with SO_ERROR or a subsequent connect(). I've seen code
    that failed if the initial connect() did not indicate an error of
    EINPROGRESS even if it in fact indicated success. (On some platforms
    an asynchronous connect() to a local socket can succeed immediately.)

    Dan Lanciani
    ddl@danlan.*com

  14. Re: select() on non-blocking socket

    On Aug 18, 1:04 am, soj wrote:

    > As far as my knowledge, there is no data to be written to or read from
    > this socket in this case, coz there is no connection established.


    Right, but that doesn't mean it's possible to wait. Not only is there
    no data to be written, but it is not possible to wait for data to be
    written. Not only is there no data to be read, but it is not possible
    to wait for data to be read.

    The question you are asking 'select' is not "is it now possible to
    read data from this socket" but "can I wait until it is possible to
    read data from this socket".

    > I'm
    > wondering, why would socket need to be set in write fd set (in Linux
    > 2.4.21 and not in Solaris 10 ) if connection is failed ?


    Because it is no longer possible to wait for the socket to be
    writable. So if you are waiting for that, you should stop waiting now.

    > This raises another question; Let's say the the connect() system call
    > on non-blocking socket to an invalid address saved EINPROGRESS to
    > errno and returned immediately; and is it possible by any means that
    > after some time, connect() would change the errno set to
    > ECONNREFUSED ?


    Before, the connect was in progress, so that's what it told you.
    Later, if the connection was refused, then 'connect' would return
    'ECONNREFUSED' to report that. The 'EINPROGRESS' tells you that a
    connection attempt is now in progress.

    > Please have a look at code I posted.


    Your code checks the values of the fd sets even if 'select' return 0
    or -1. That's bad mojo.

    DS


  15. Re: select() on non-blocking socket

    On Aug 19, 1:49 am, Barry Margolin wrote:
    > In article <1187424291.702075.7...@q4g2000prc.googlegroups.com>,
    >
    > soj wrote:
    > > Hi Dan,

    >
    > > As far as my knowledge, there is no data to be written to or read from
    > > this socket in this case, coz there is no connection established. I'm
    > > wondering, why would socket need to be set in write fd set (in Linux
    > > 2.4.21 and not in Solaris 10 ) if connection is failed ?

    >
    > > This raises another question; Let's say the the connect() system call
    > > on non-blocking socket to an invalid address saved EINPROGRESS to
    > > errno and returned immediately; and is it possible by any means that
    > > after some time, connect() would change the errno set to
    > > ECONNREFUSED ?

    >
    > What do you mean by "invalid address"? If it's an address of a machine
    > that's up but not running a server on the port you're connecting to,
    > select() should report the socket as writable, and your new call to
    > connect() should set errno to ECONNREFUSED (just like it would if you
    > were using a blocking socket). But if there's no machine with that
    > address, it will eventually set it to ETIMEDOUT.
    >
    > --
    > Barry Margolin, bar...@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***


    Hi
    By "invalid address" i mean, this address is not being assigned to any
    system in our subnet.
    I've a question on the point you said; "Using a
    non-blocking socket and select() doesn't change this -- the TCP stack
    still gives up trying to connect after a few minutes. When this
    happens, select() returns with the socket marked writable, and when
    you
    call connect() again you'll get that errno. ",

    But why socket is being marked as writable in this case? why it is not
    happening in Solaris 10?

    Thanks & Rgds,
    --soj



  16. Re: select() on non-blocking socket

    On Aug 19, 10:23 am, David Schwartz wrote:
    > On Aug 18, 1:04 am, soj wrote:
    >
    > > As far as my knowledge, there is no data to be written to or read from
    > > this socket in this case, coz there is no connection established.

    >
    > Right, but that doesn't mean it's possible to wait. Not only is there
    > no data to be written, but it is not possible to wait for data to be
    > written. Not only is there no data to be read, but it is not possible
    > to wait for data to be read.
    >
    > The question you are asking 'select' is not "is it now possible to
    > read data from this socket" but "can I wait until it is possible to
    > read data from this socket".
    >
    > > I'm
    > > wondering, why would socket need to be set in write fd set (in Linux
    > > 2.4.21 and not in Solaris 10 ) if connection is failed ?

    >
    > Because it is no longer possible to wait for the socket to be
    > writable. So if you are waiting for that, you should stop waiting now.
    >
    > > This raises another question; Let's say the the connect() system call
    > > on non-blocking socket to an invalid address saved EINPROGRESS to
    > > errno and returned immediately; and is it possible by any means that
    > > after some time, connect() would change the errno set to
    > > ECONNREFUSED ?

    >
    > Before, the connect was in progress, so that's what it told you.
    > Later, if the connection was refused, then 'connect' would return
    > 'ECONNREFUSED' to report that. The 'EINPROGRESS' tells you that a
    > connection attempt is now in progress.
    >



    As the socket is being non-blocking, there is no way to get
    ECONNREFUSED from the first connect() call. It will return
    'EINPROGRESS' in both Linux and Solaris. Later the connect() would
    have failed, but not sure if it save errno to 'ECONNREFUSED'.


    > > Please have a look at code I posted.

    >
    > Your code checks the values of the fd sets even if 'select' return 0
    > or -1. That's bad mojo.



    Yep, I agree , It's just a sample code to see the behavior, my
    protocol stack code is fine for this matter


    > DS



  17. Re: select() on non-blocking socket

    In article <1187546433.656090.208590@q4g2000prc.googlegroups.c om>, jul.sfx@gmail.com (soj) writes:

    | As the socket is being non-blocking, there is no way to get
    | ECONNREFUSED from the first connect() call.

    This is a very dangerous assumption. As I mentioned previously, I've
    seen platforms where it is possible for the first asynchronous connect()
    to actually succeed (i.e., no EINPROGRESS at all) when the listener is
    local. I suspect that those platforms could similarly produce an error
    of ECONNREFUSED immediately if the connect() is to the local machine and
    there is no listening socket.

    Getting back to the Solaris/Linux difference; how long did you wait in
    the Solaris case?

    Dan Lanciani
    ddl@danlan.*com

  18. Re: select() on non-blocking socket

    In article <1187545925.686496.183970@q3g2000prf.googlegroups.c om>,
    soj wrote:

    > But why socket is being marked as writable in this case? why it is not
    > happening in Solaris 10?


    Because when the connection attempt times out, a call to write() would
    return immediately with an error, not block.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  19. Re: select() on non-blocking socket

    On Aug 19, 10:52 am, soj wrote:

    > I've a question on the point you said; "Using a
    > non-blocking socket and select() doesn't change this -- the TCP stack
    > still gives up trying to connect after a few minutes. When this
    > happens, select() returns with the socket marked writable, and when
    > you
    > call connect() again you'll get that errno. ",


    > But why socket is being marked as writable in this case?


    Because it is no longer possible to wait for the socket to become
    writable. If the socket wasn't marked writable, it would be almost
    impossible to write sane code, since you'd have no idea why 'select'
    stopped waiting. With the socket market writable, you will attempt a
    write (or call 'connect' again, or whatever) and detect that the
    connection attempt failed.

    > why it is not
    > happening in Solaris 10?


    Post the smallest code that demonstrates this problem. Perhaps there's
    a subtle bug in it.

    DS


+ Reply to Thread