Reconnecting after failure, should that work?

[Saúl Ibarra Corretgé]

Hi!

I was writing a TCP client application, which does getaddrinfo and
attempts to connect to the result addresses until it succeeds. There is
no server at the other end, so I expected all attempts to fail. However,
while the first attempt fails with ECONNREFUSED, the next one fails with
EINVAL, which was a bit surprising to me.

I tracked it down to the very connect() syscall, it returns EINVAL. Is
this expected? This was on OSX, FWIW.

Here [0] is a test script written with pyuv, I can translate it to C if
needed, but it was easier for me to test in Python ;-)

Am I doing something terribly wrong here?

Thanks!


[0]: https://gist.github.com/saghul/5476393

--
Sa�l Ibarra Corretg�
http://about.me/saghul | http://saghul.net

[Saúl Ibarra Corretgé]

Hum, according to this answer on stackoverflow
http://stackoverflow.com/a/4200797/280310 backing off a little bit would
make it work. However even with a 5 second pause I'm getting the same error.

Is there a way to do this without destroying and recreating TCP handles
(that works) ?

[Ben Noordhuis]

The short answer is no, not reliably; the socket becomes effectively
unusable. It can end up in one of several states (CLOSE_WAIT,
TIME_WAIT, possibly others) depending on the actual sequence of events
(SYN followed by RST, SYN/ACK followed by RST, etc.) and there is no
foolproof way to recover from that, even if all the TCP stacks
implemented the exact same behavior (which they don't.)

[Saúl Ibarra Corretgé]

>
> The short answer is no, not reliably; the socket becomes effectively
> unusable. It can end up in one of several states (CLOSE_WAIT,
> TIME_WAIT, possibly others) depending on the actual sequence of events
> (SYN followed by RST, SYN/ACK followed by RST, etc.) and there is no
> foolproof way to recover from that, even if all the TCP stacks
> implemented the exact same behavior (which they don't.)
>

Doh, I'll stick to recreating the handles then. Thanks for the
explanation Ben!