TCP connect in Non Blocking Mode - Unix

This is a discussion on TCP connect in Non Blocking Mode - Unix ; Hi, My client application tries to connect to the server in the following manner: ...../ err = connect(sd, (struct sockaddr*) &sa, sizeof(sa)); if(err == -1) { if(errno == EINPROGRESS) { struct timeval l_connect_timeout; int l_fds; l_connect_timeout.tv_usec=0; l_connect_timeout.tv_sec=30; //30 seconds. while(1) ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: TCP connect in Non Blocking Mode

  1. TCP connect in Non Blocking Mode

    Hi,

    My client application tries to connect to the server in the following
    manner:

    ...../
    err = connect(sd, (struct sockaddr*) &sa, sizeof(sa));

    if(err == -1)
    {
    if(errno == EINPROGRESS)
    {
    struct timeval l_connect_timeout;
    int l_fds;
    l_connect_timeout.tv_usec=0;
    l_connect_timeout.tv_sec=30; //30 seconds.

    while(1)
    {
    l_fds=select(sd+1, NULL,&filedes_set,NULL,
    &l_connect_timeout);
    if(l_fds == 0) //timed out
    return 0;
    else if(l_fds < 0) //select failed
    return 0;
    else
    {
    int l_sock_optval=-1;
    int
    l_sock_optval_len=sizeof(l_sock_optval);
    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)
    {
    //connected to
    server
    break;
    }
    }

    }

    }

    This works fine. The issue that I face is when the server refuses
    connection by sending RST for the SYN from client. The select waits
    for 30 seconds and later returns timing out. RST though is sent
    immediately by the server. The client application need to capture the
    RST as soon as it arrives. How do we achieve that. Why does not the
    select return immediately when the RST arrives at client?

    Thanks,
    Prabhu. S

  2. Re: TCP connect in Non Blocking Mode

    Prabhu wrote:
    > err = connect(sd, (struct sockaddr*) &sa, sizeof(sa));

    .....
    > l_fds=select(sd+1, NULL,&filedes_set,NULL,&l_connect_timeout);


    > This works fine. The issue that I face is when the server refuses
    > connection by sending RST for the SYN from client. The select waits
    > for 30 seconds and later returns timing out. RST though is sent
    > immediately by the server. The client application need to capture the
    > RST as soon as it arrives. How do we achieve that. Why does not the
    > select return immediately when the RST arrives at client?


    Have you tried to select() the filedescriptor for read (in the
    read-fd-set) as well?

  3. Re: TCP connect in Non Blocking Mode

    On Apr 23, 9:44 am, Rainer Temme
    wrote:
    > Prabhu wrote:
    > > err = connect(sd, (struct sockaddr*) &sa, sizeof(sa));

    > ....
    > > l_fds=select(sd+1, NULL,&filedes_set,NULL,&l_connect_timeout);
    > > This works fine. The issue that I face is when the server refuses
    > > connection by sending RST for the SYN from client. The select waits
    > > for 30 seconds and later returns timing out. RST though is sent
    > > immediately by the server. The client application need to capture the
    > > RST as soon as it arrives. How do we achieve that. Why does not the
    > > select return immediately when the RST arrives at client?

    >
    > Have you tried to select() the filedescriptor for read (in the
    > read-fd-set) as well?


    He's trying to connect. Checking for readability doesn't make sense
    unless he has nothing else to do until the other side sends him any
    data.

    DS

  4. Re: TCP connect in Non Blocking Mode

    David Schwartz wrote:
    > On Apr 23, 9:44 am, Rainer Temme
    > wrote:
    >> Prabhu wrote:
    >>> err = connect(sd, (struct sockaddr*) &sa, sizeof(sa));

    >> ....
    >>> l_fds=select(sd+1, NULL,&filedes_set,NULL,&l_connect_timeout);
    >>> This works fine. The issue that I face is when the server refuses
    >>> connection by sending RST for the SYN from client. The select waits
    >>> for 30 seconds and later returns timing out. RST though is sent
    >>> immediately by the server. The client application need to capture the
    >>> RST as soon as it arrives. How do we achieve that. Why does not the
    >>> select return immediately when the RST arrives at client?

    >> Have you tried to select() the filedescriptor for read (in the
    >> read-fd-set) as well?

    >
    > He's trying to connect. Checking for readability doesn't make sense
    > unless he has nothing else to do until the other side sends him any
    > data.


    Acutally, select() poll() do NOT check for readablity but for
    the ability to call read() without being blocked in the call.
    Since the connection is refused by the RST, read() should
    return iommediately with result -1 and errno set to ECONNREFUSED.
    And select() should indicate that a read() can be called without
    being blocked.

    Rainer

  5. Re: TCP connect in Non Blocking Mode

    On Apr 25, 1:59 pm, Rainer Temme
    wrote:

    > > He's trying to connect. Checking for readability doesn't make sense
    > > unless he has nothing else to do until the other side sends him any
    > > data.


    > Acutally, select() poll() do NOT check for readablity but for
    > the ability to call read() without being blocked in the call.
    > Since the connection is refused by the RST, read() should
    > return iommediately with result -1 and errno set to ECONNREFUSED.
    > And select() should indicate that a read() can be called without
    > being blocked.


    But a 'write' can be called without being blocked too, so checking for
    readability is at best redundant. If the connection succeeds, it will
    be writable but not readable, so checking for 'read'ability won't
    detect connection success.

    This is why the typical pattern is to check an asynchronous 'connect'
    attempt only for writability.

    DS

  6. Re: TCP connect in Non Blocking Mode

    David Schwartz wrote:
    >> Acutally, select() poll() do NOT check for readablity but for
    >> the ability to call read() without being blocked in the call.
    >> Since the connection is refused by the RST, read() should
    >> return iommediately with result -1 and errno set to ECONNREFUSED.
    >> And select() should indicate that a read() can be called without
    >> being blocked.

    >
    > But a 'write' can be called without being blocked too, so checking for
    > readability is at best redundant. If the connection succeeds, it will
    > be writable but not readable, so checking for 'read'ability won't
    > detect connection success.
    >
    > This is why the typical pattern is to check an asynchronous 'connect'
    > attempt only for writability.


    Whether a socket will become readable after connect
    also depends on the protocol used ... SMTP and FTP
    are exaples of protocols where the serverside
    will send an immediate message to the client
    after successful connection.
    Anyhow, my suggestion was to set the bit in the readset
    as well as in the writeset. You might regard this as redundant
    but (as even you had to admit) it will not harm.
    By the way ... setting the bit in the exceptionset will also
    not harm.

    Rainer

  7. Re: TCP connect in Non Blocking Mode

    Rainer Temme writes:
    > David Schwartz wrote:


    [...]

    >> If the connection succeeds, it will be writable but not readable,
    >> so checking for 'read'ability won't detect connection success.
    >> This is why the typical pattern is to check an asynchronous 'connect'
    >> attempt only for writability.

    >
    > Whether a socket will become readable after connect
    > also depends on the protocol used ... SMTP and FTP
    > are exaples of protocols where the serverside
    > will send an immediate message to the client
    > after successful connection.
    > Anyhow, my suggestion was to set the bit in the readset
    > as well as in the writeset. You might regard this as redundant
    > but (as even you had to admit) it will not harm.


    The to-be-expected behaviour is actually standardized:

    If the connection cannot be established immediately and
    O_NONBLOCK is set for the file descriptor for the socket,
    connect() shall fail and set errno to [EINPROGRESS], but the
    connection request shall not be aborted, and the connection
    shall be established asynchronously. Subsequent calls to
    connect() for the same socket, before the connection is
    established, shall fail and set errno to [EALREADY].

    When the connection has been established asynchronously,
    select() and poll() shall indicate that the file descriptor
    for the socket is ready for writing.

    http://www.opengroup.org/onlinepubs/...s/connect.html

    Additionally, 'cargo cult programming'

    http://catb.org/jargon/html/C/cargo-...ogramming.html

    does harm. It causes the technical damage of keeping the machine busy
    with doing useless instead of useful things. But that's the less
    serious problem. The much more serious one is that code is
    harder to understand and change meaningfully when it is more
    complicated and the most complicated thing to understand is something
    which defies understanding because it is inherently without meaning.
    The latter becomes especially nasty when someone different from the
    original author inherits the code.


  8. Re: TCP connect in Non Blocking Mode

    Rainer Weikusat wrote:
    > Rainer Temme writes:
    >> David Schwartz wrote:

    > [...]
    >>> If the connection succeeds, it will be writable but not readable,
    >>> so checking for 'read'ability won't detect connection success.
    >>> This is why the typical pattern is to check an asynchronous 'connect'
    >>> attempt only for writability.

    >> Whether a socket will become readable after connect
    >> also depends on the protocol used ... SMTP and FTP
    >> are exaples of protocols where the serverside
    >> will send an immediate message to the client
    >> after successful connection.
    >> Anyhow, my suggestion was to set the bit in the readset
    >> as well as in the writeset. You might regard this as redundant
    >> but (as even you had to admit) it will not harm.

    >
    > The to-be-expected behaviour is actually standardized:
    >
    > If the connection cannot be established immediately and
    > O_NONBLOCK is set for the file descriptor for the socket,
    > connect() shall fail and set errno to [EINPROGRESS], but the
    > connection request shall not be aborted, and the connection
    > shall be established asynchronously. Subsequent calls to
    > connect() for the same socket, before the connection is
    > established, shall fail and set errno to [EALREADY].
    >
    > When the connection has been established asynchronously,
    > select() and poll() shall indicate that the file descriptor
    > for the socket is ready for writing.
    >
    > http://www.opengroup.org/onlinepubs/...s/connect.html


    This does not specify the case where a blocking connect() would have
    failed, which is the issue at hand.

    > Additionally, 'cargo cult programming'
    >
    > http://catb.org/jargon/html/C/cargo-...ogramming.html
    >
    > does harm. It causes the technical damage of keeping the machine busy
    > with doing useless instead of useful things. [...]


    I agree, but the only reason I can think of for considering Rainer
    Temme's suggestion is such is not reading the thread.

    Alex

  9. Re: TCP connect in Non Blocking Mode

    Alex Fraser writes:
    > Rainer Weikusat wrote:
    >> Rainer Temme writes:
    >>> David Schwartz wrote:

    >> [...]
    >>>> If the connection succeeds, it will be writable but not readable,
    >>>> so checking for 'read'ability won't detect connection success.
    >>>> This is why the typical pattern is to check an asynchronous 'connect'
    >>>> attempt only for writability.
    >>> Whether a socket will become readable after connect
    >>> also depends on the protocol used ... SMTP and FTP
    >>> are exaples of protocols where the serverside
    >>> will send an immediate message to the client
    >>> after successful connection.
    >>> Anyhow, my suggestion was to set the bit in the readset
    >>> as well as in the writeset. You might regard this as redundant
    >>> but (as even you had to admit) it will not harm.

    >> The to-be-expected behaviour is actually standardized:
    >> If the connection cannot be established immediately and
    >> O_NONBLOCK is set for the file descriptor for the socket,
    >> connect() shall fail and set errno to [EINPROGRESS], but the
    >> connection request shall not be aborted, and the connection
    >> shall be established asynchronously. Subsequent calls to
    >> connect() for the same socket, before the connection is
    >> established, shall fail and set errno to [EALREADY].
    >> When the connection has been established
    >> asynchronously,
    >> select() and poll() shall indicate that the file descriptor
    >> for the socket is ready for writing.
    >>
    >> http://www.opengroup.org/onlinepubs/...s/connect.html

    >
    > This does not specify the case where a blocking connect() would have
    > failed, which is the issue at hand.


    It specifies the case I was refering to, which happened to be the one
    the discussion had moved to at this point, cf

    ,----
    | If the connection succeeds, it will be writable but not
    | readable, so checking for 'read'ability won't detect
    | connection success.
    `----

    and

    ,----
    | Whether a socket will become readable after connect
    | also depends on the protocol used ... SMTP and FTP
    `----

    >> Additionally, 'cargo cult programming'
    >> http://catb.org/jargon/html/C/cargo-...ogramming.html
    >> does harm. It causes the technical damage of keeping the machine busy
    >> with doing useless instead of useful things. [...]

    >
    > I agree, but the only reason I can think of for considering Rainer
    > Temme's suggestion is such is not reading the thread.


    Comparing

    ,----
    | Anyhow, my suggestion was to set the bit in the readset
    | as well as in the writeset. You might regard this as redundant
    | but (as even you had to admit) it will not harm.
    `----

    with

    ,----
    | A style of programming dominated by ritual inclusion of code
    | or program structures that serve no real purpose. A cargo cult
    | programmer will usually explain the extra code as a way of
    | working around some bug encountered in the past,
    `----

    I consider the first text to be a near-perfect example of what is
    described in the second. If it is or it isn't is completely
    independent of anything related to me, and your ad hominem is
    therefore besides the point.





  10. Re: TCP connect in Non Blocking Mode

    On Apr 28, 2:56 am, Rainer Weikusat wrote:

    > I consider the first text to be a near-perfect example of what is
    > described in the second. If it is or it isn't is completely
    > independent of anything related to me, and your ad hominem is
    > therefore besides the point.


    It is also extremely unhelpful to suggest that novices do something
    useless even though it's harmless. At best, it will confuse them.
    That's why I replied explaining that there is almost never any good
    reason to do that.

    DS

  11. Re: TCP connect in Non Blocking Mode

    On Apr 28, 7:39 am, David Schwartz wrote:

    >
    > It is also extremely unhelpful to suggest that novices do something
    > useless even though it's harmless. ..


    To bring the discussion from "ad hominem" back to "ad rem":

    Is it or is it not necessary to set the bit in readset if you
    want
    select to return immediately on "connection refused"? (This
    was the point of the OP.)

    At first I thought the answer was "yes", but then people called
    it "cargo cult programming", which implies "no." So now
    I'm confused.

    I can think of 3 possible answers:

    1. It is necessary. In that case, it is _not_ useless, unless
    for
    some reason you would rather wait the 30 seconds
    to get the connection refused error.

    2. It is not necessary, the bit in writeset is enough. If so,
    we of the great unwashed would like to know what was
    wrong with the OP's program.

    3. It is not necessary, you need to do Y. If so,
    please tell us Y.

    Arguing about who is doing "cargo cult programming" may
    make you feel wise, but it is just confusing for those of
    us who don't already know all the anwers.


  12. Re: TCP connect in Non Blocking Mode


    Alan McKenney wrote:

    > Is it or is it not necessary to set the bit in readset if you
    > want
    > select to return immediately on "connection refused"? (This
    > was the point of the OP.)


    Of course not.

    > At first I thought the answer was "yes", but then people called
    > it "cargo cult programming", which implies "no." So now
    > I'm confused.


    Why would you think the answer would be yes? If the connection
    succeeds, a write will not block. So selecting for writability will
    detect this case. If the connection fails, a write will not block. So
    selecting for writability will detect this case.

    > I can think of 3 possible answers:
    >
    > 1. It is necessary. In that case, it is _not_ useless, unless
    > for
    > some reason you would rather wait the 30 seconds
    > to get the connection refused error.


    Nope.

    > 2. It is not necessary, the bit in writeset is enough. If so,
    > we of the great unwashed would like to know what was
    > wrong with the OP's program.


    Nothing is wrong with the OP's program at the top of this thread.

    > 3. It is not necessary, you need to do Y. If so,
    > please tell us Y.
    >
    > Arguing about who is doing "cargo cult programming" may
    > make you feel wise, but it is just confusing for those of
    > us who don't already know all the anwers.


    He has said that selecting for readability is cargo cult programming.
    It is being done for no good reason, as some kind of magic charm
    that's supposed to make some uncomprehended bug go away.

    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.

    DS

  13. Re: TCP connect in Non Blocking Mode

    Rainer Weikusat wrote:
    [snip]
    > It specifies the case I was refering to, which happened to be the one
    > the discussion had moved to at this point [...]


    OK, so you were responding only to the suggestion of also checking for
    readability, ignoring the reason for that suggestion, right? The context
    seemed (and still seems) important to me, so ignoring it came across
    like you hadn't read it.

    Put another way, there is a difference between "set the pointer to NULL
    after calling free()" and "set pointers to NULL after calling free()" -
    you seem to be responding to the former as if it were the latter.

    Alex

  14. Re: TCP connect in Non Blocking Mode

    David Schwartz wrote:
    [snip]
    > Why would you think the answer would be yes? If the connection
    > succeeds, a write will not block. So selecting for writability will
    > detect this case. If the connection fails, a write will not block. So
    > selecting for writability will detect this case.

    [snip]
    > Nothing is wrong with the OP's program at the top of this thread.


    The OP wrote that "when the server refuses connection ... select waits
    for 30 seconds and later returns timing out."

    If this is true, either there *is* something wrong with the OP's code or
    selecting for writability *does not* detect this case (for the OP).

    I believe this was Alan's point.

    [snip]
    > 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?

    Alex

  15. Re: TCP connect in Non Blocking Mode

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

    > OK, so you were responding only to the suggestion of also checking for
    > readability, ignoring the reason for that suggestion, right? The context
    > seemed (and still seems) important to me, so ignoring it came across
    > like you hadn't read it.


    Going back, the original post was:

    >>> l_fds=select(sd+1, NULL,&filedes_set,NULL,&l_connect_timeout);
    >>> This works fine. The issue that I face is when the server refuses
    >>> connection by sending RST for the SYN from client. The select waits
    >>> for 30 seconds and later returns timing out. RST though is sent
    >>> immediately by the server. The client application need to capture the
    >>> RST as soon as it arrives. How do we achieve that. Why does not the
    >>> select return immediately when the RST arrives at client?


    And the response was:

    >>Have you tried to select() the filedescriptor for read (in the
    >>read-fd-set) as well?


    These is no reason to think that checking for readability would have
    any effect on the case where the connection is rejected. If the
    connection attempt terminates due to error, it is no longer possible
    to wait for readability or writability.

    You are correct that the excerpt Rainer posted doesn't make this
    clear.

    The normal pattern is to 'select' or 'poll' for writability to detect
    when an asynchronous connection has succeeded of failed. There is
    normally no reason to select for readability as well.

    The only way I can imagine it would even be useful at all would be if
    you used a pattern where one thread checks for readability and one
    checks for writability. In that case, it would save you from having to
    redispatch the thread checking for readability after the connection
    completed successfully. In exchange, both threads would abort from
    'select' or 'poll' if the connection failed, leading to some extra
    cost and complexity. If connections almost always succeed, it might be
    worth it though.

    But it should definitely *NOT* be casually advised. It's simply not
    the correct pattern.

    DS

  16. Re: TCP connect in Non Blocking Mode

    David Schwartz wrote:
    > On Apr 28, 3:12 pm, Alex Fraser wrote:
    >
    >> OK, so you were responding only to the suggestion of also checking for
    >> readability, ignoring the reason for that suggestion, right? The context
    >> seemed (and still seems) important to me, so ignoring it came across
    >> like you hadn't read it.

    >
    > Going back, the original post was:
    >
    >>>> l_fds=select(sd+1, NULL,&filedes_set,NULL,&l_connect_timeout);
    >>>> This works fine. The issue that I face is when the server refuses
    >>>> connection by sending RST for the SYN from client. The select waits
    >>>> for 30 seconds and later returns timing out. RST though is sent
    >>>> immediately by the server. The client application need to capture the
    >>>> RST as soon as it arrives. How do we achieve that. Why does not the
    >>>> select return immediately when the RST arrives at client?

    >
    > And the response was:
    >
    >>> Have you tried to select() the filedescriptor for read (in the
    >>> read-fd-set) as well?

    >
    > These is no reason to think that checking for readability would have
    > any effect on the case where the connection is rejected. [...]


    I would say there is no reason to think it wouldn't, given that checking
    for writeability doesn't have the expected effect in that case.

    > The normal pattern is to 'select' or 'poll' for writability to detect
    > when an asynchronous connection has succeeded of failed. There is
    > normally no reason to select for readability as well.


    Agreed.

    Alex

  17. Re: TCP connect in Non Blocking Mode

    Alex Fraser writes:
    > Rainer Weikusat wrote:
    > [snip]
    >> It specifies the case I was refering to, which happened to be the one
    >> the discussion had moved to at this point [...]

    >
    > OK, so you were responding only to the suggestion of also checking for
    > readability, ignoring the reason for that suggestion, right?
    > The context seemed (and still seems) important to me,


    Then why are continously ignoring the context of my original posting?
    This was addressed at two (quoted) general remarks regarding
    asynchronous connection establishment: This is supposed to work by
    waiting for a descriptor to become writable.

    Coming back to the original context: Obviously, an attempt to
    establish a connection asychronously can fail. While this isn't
    explicitly addressed in the standard text I quoted, 'selecting for
    writeable' can only be used for asychronous connection establishment
    if 'failure to establish a connection asynchronously' is reported in
    this way, too. For Linux, this is documented behaviour. The same as
    true for some other operating systems (eg NetBSD, OpenBSD, HP-UX
    11.22) and not entirely clear for Solaris. Nevertheless, the 'crucial'
    sentence (for select) is

    A descriptor shall be considered ready for writing when a call
    to an output function with O_NONBLOCK clear would not block,
    whether or not the function would transfer data successfully.

    Without at least knowing the OS where this phenomenon occurs, that's
    all what can be said here. Looking at the code, a not unlikely guess
    would be that the OS is Linux or some other system which documents the
    implemented procedure as method to determine if an asynchronous
    connection attempt failed.


  18. Re: TCP connect in Non Blocking Mode

    On Apr 28, 7:00 pm, Alex Fraser wrote:
    > David Schwartz wrote:
    > > On Apr 28, 3:12 pm, Alex Fraser wrote:

    >
    > >> OK, so you were responding only to the suggestion of also checking for
    > >> readability, ignoring the reason for that suggestion, right? The context
    > >> seemed (and still seems) important to me, so ignoring it came across
    > >> like you hadn't read it.

    >
    > > Going back, the original post was:

    >
    > >>>> l_fds=select(sd+1, NULL,&filedes_set,NULL,&l_connect_timeout);
    > >>>> This works fine. The issue that I face is when the server refuses
    > >>>> connection by sending RST for the SYN from client. The select waits
    > >>>> for 30 seconds and later returns timing out. RST though is sent
    > >>>> immediately by the server. The client application need to capture the
    > >>>> RST as soon as it arrives. How do we achieve that. Why does not the
    > >>>> select return immediately when the RST arrives at client?

    >
    > > And the response was:

    >
    > >>> Have you tried to select() the filedescriptor for read (in the
    > >>> read-fd-set) as well?

    >
    > > These is no reason to think that checking for readability would have
    > > any effect on the case where the connection is rejected. [...]

    >
    > I would say there is no reason to think it wouldn't, given that checking
    > for writeability doesn't have the expected effect in that case.
    >
    > > The normal pattern is to 'select' or 'poll' for writability to detect
    > > when an asynchronous connection has succeeded of failed. There is
    > > normally no reason to select for readability as well.

    >
    > Agreed.
    >
    > Alex


    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?


    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.

    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.

    + +

    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.

  19. Re: TCP connect in Non Blocking Mode

    Alex Fraser writes:
    > David Schwartz wrote:
    >> On Apr 28, 3:12 pm, Alex Fraser wrote:


    [...]

    >>>> Have you tried to select() the filedescriptor for read (in the
    >>>> read-fd-set) as well?

    >> These is no reason to think that checking for readability would have
    >> any effect on the case where the connection is rejected. [...]

    >
    > I would say there is no reason to think it wouldn't, given that
    > checking for writeability doesn't have the expected effect in that
    > case.


    Actually, there _is_ a reason and that would be that a socket is
    supposed to become readable when it has a pending error. But there is
    no logical relation between the two and that feature a) apparently
    doesn't work as it is supposed to be conveys no information regarding
    feature b), except the faint hint that the implementation of feature A
    could already be buggy.

    But without at least knowing what OS was used and how it is supposed
    to behave, this is all just random speculation.


  20. Re: TCP connect in Non Blocking Mode

    Alan McKenney writes:

    [...]

    > 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?
    >
    >
    > 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.
    >
    > 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.


    Assuming that you have no real idea why the old code is doing this
    particular thing, are (for some reason) not in the position to
    determine the behaviour experimentally and (for some other reason) not
    in the position to determine it from the published source code either,
    the safe suggestion is use poll not select. The problem doesn't exist
    there.

+ Reply to Thread
Page 1 of 2 1 2 LastLast