Re: TCP connect in Non Blocking Mode

On Apr 28, 3:12 pm, Alex Fraser <m...@xxxxxxxxxxx> 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
.

Relevant Pages

  • Re: TCP connect in Non Blocking Mode
    ... connection by sending RST for the SYN from client. ... any effect on the case where the connection is rejected. ... I would say there is no reason to think it wouldn't, ... normally no reason to select for readability as well. ...
    (comp.unix.programmer)
  • Re: TCP connect in Non Blocking Mode
    ... seemed important to me, so ignoring it came across ... connection by sending RST for the SYN from client. ... 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. ... normally no reason to select for readability as well. ...
    (comp.unix.programmer)
  • Re: TCP connect in Non Blocking Mode
    ... the ability to call readwithout being blocked in the call. ... Since the connection is refused by the RST, ... readability is at best redundant. ... attempt only for writability. ...
    (comp.unix.programmer)
  • Re: Betovs notation
    ... That might apply to RosAsm... ... >:)) You just give the reason why an Assembler should NEVER ... That's not Nasm syntax, maybe it's LuxAsm syntax... ... > the readability, ... ...
    (alt.lang.asm)
  • Re: 5 inch floppies
    ... >> Trying to mount with a mount command also results ... >> Is there a reason that the directory ... readability between the directory and other files? ... Would it help to replace the fstab entry with something else? ...
    (Fedora)