Sounds like you are agreeing with me. The code in the OP could get really nasty. There are things that will cause connect to fail that won't take the 1 second timeout time. Server could get flooded with millions of connect requests per second.

I showed a fixed one second delay, but better is some variation to move us out of some possible "sync" with others trying to do the same thing. Many retry algorithms implement back-off at an exponential rate to some limit (does a few retries real fast, then starts lengthening the time between retries).

The main point is not to make any recursive calls. 

my $socket;
my $max_tries = 50;
my $cur_try = 0;

while ( ($cur_try++ < $max_tries)  and
         !$socket = IO::Socket::INET->new (
                     Proto            => "tcp",
                     PeerAddr    => "192.168.1.105",
                     PeerPort        => "5000",
                     Timeout        => "1")
       )
{
    sleep 1;
    sleep 1 if (rand() > .5); #some variance is good
}

[download]
As far as doing something when the server goes away. A common scheme would be like this: 
$SIG{ALRM} = 'ALRMhandler';
my $line;
while ( alarm(30), $line=<$socket>, defined($line) )
{
   alarm(0);  #turn off alarm
   ... process data in $line ....
}
...here if $line is not defined....
...another possible "server went away" condition...

sub ALRMhandler
{
   ...see discussion...
}

[download]
The read is blocking. We could get some characters, but not enough to get us to the \n character, we get "stuck" part way though the reading. So we set alarm to some number of seconds, I just randomly picked 30 seconds. When a defined string is returned, the statement completes and we move into the body of the loop. That immediately turns off the alarm and processes the data. Next iteration does the same thing.

If for some reason, the read returns an undef value, then we are not in the loop and that means that server went away.

What happens in the "fall through loop" or ALRM signal depends upon the application. Log an error message perhaps. Then maybe restart the app. redo label will go back to label:. I think this is "safe" in Perl. But heck even just completely restarting by exec'ing the same Perl script again might be just fine also. What's appropriate is up to the OP's goal with his application.

In reply to Re^3: IO::Socket client does not detect when server network connection dies by Marshall
in thread IO::Socket client does not detect when server network connection dies by bkchris

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.