comment on

I would approach the problem using the following steps (maybe not in exactly the same order):

Style: A little indentation helps to comprehend the code easier and also helps to get answers faster from the Monks trying to help you.
Style: add usestrict; usewarnings; / correct errors / reflect warnings
Error checking. Add some error checks (e.g. where DBI is used).
Debugging: Where does the blocking occur? Add some logging, e.g. at least where new process is forked and where the connection to the DB is established. The DB-connection might need a timeout plus error-handling.
Program logic: Why create/delete a server socket in the outer loop? Creating it once should be sufficient. Each incoming connection (accept()) gets a fresh process to handle the new connection. So, getting rid of while(1) and close $sock; makes code cleaner and (I am not sure here) reduces the chance of race conditions.
Protocol design: I would re-think a design that assumes that a connection is established/in-use for an infinite amount of time. Close connections after some idle-time. That saves resources and can help to (later) make fail-over scenarios easier (e.g. by means of a load balancer). If a permanent connection is a mandatory requirement, at least use some keep-alive messages during idle times to verify proper connection/application state.
OS: Seems, this script is operating in a UNIXish environment (POSIX, Sys::hostname, !#...). Does netstat or lsof reveal something unusual? Number of filehandles available to the process could be a limiting factor too (see ulimit).
Networking: Blocking can happen outside the script between client and server. I have seen situations where a firewall silently dropped packets of a connection that has been idle for too long. Using keep-alive messages can help if you have influence on the client side (seems this is a proprietary protocol?). Some TCP stacks can be configured for keep-alive messages too (not recommended!).
Re-use: This is common server programming. Chances are high, you find a suitable module on CPAN..., e.g. Net::Server.

HTH

Update (in response to Re^2: IO::Socket Not responding after period of time and traffic!):
Sorry, when I meant get rid of while(1), I was possibly not precise enough. You still need an infinite loop to accept() new connections, but you do not need to create/kill the server socket itself. See the following annotated modifications to your script... I used #-- for removed lines, #++ for lines added, and #!! to indicate your shame ;-)

#!/usr/bin/perl


#!! use strict;
#!! use warnings;

use IO::Socket;
use IO::Handle;

use Sys::Hostname;
use POSIX qw(:sys_wait_h);

#++  see advice of other monks regarding REAP (not applied here)
#++2 just to clarify, THIS is YOUR version of sub REAP ;-) (well, warn
+(..) added for debugging purpose)
#++3 please study "perldoc perlipc" carefully - it holds a full sample
+ of a spawning server, that you 
#++3 could easily adapt - or see CPAN Net::Server (i.e.)
sub REAP {
  warn("REAP... \n"); #++
  1 until (-1 == waitpid(-1, WNOHANG));
  $SIG{CHLD} = \&REAP;
}
$SIG{CHLD} = \&REAP;


#--(this would create/destroy the sever socket - don't!)
#--    while (1) {
  my $sock = new IO::Socket::INET (
                   LocalHost => 'localhost',
                   LocalPort => '1818',
                   Proto => 'tcp',
                   Listen => 255,
                   Reuse => 1,
                   Timeout => '15',);
  $sock or die "no socket :$!";
  STDOUT->autoflush(1);
  my($new_sock, $buf, $kid);


#--  while ($new_sock = $sock->accept()) {
while (1) { #++  endlessly accept new connections 
            #++  accept() blocks or timeouts after 15s (here)
  warn ("Sever waiting...\n"); #++
  if ($new_sock = $sock->accept()) { #++
    $new_sock->autoflush(1);
    warn "New client...\n"; #++
    # execute a fork, if this is
    # the parent, its work is done,
    # go straight to continue
    next if $kid = fork;
    die "fork: $!" unless defined $kid;
    # child now...
    # close the server - not needed
#--(you want the server socket to survive!)
#--    close $sock ;

    warn("Child ($$) reading...\n"); #++
    while (defined($buf = <$new_sock>)) {

#---- removed distracting stuff

      #++ minimum functionality added
      print $new_sock "ECHO ($$): $buf\n"; #++
      last if $buf =~ /quit/;              #++

    $new_sock->flush;

#-- Alas! Code formatting, Grashopper!
#--      }
    }
    warn "Child ($$) quits.\n"; #++
    close $new_sock; #++ (well, explicite here since exit() would clos
+e() it for you...)
    exit;
#--  } continue {
    # parent closes the client since
    # it is not needed
#--    close $new_sock;
  } else { #++
    #++ Check if a problem occured or a signal was received...(see per
+lipc).
    #++ Since Timeout=>15, this will be visited every 15s! Chose Timeo
+ut=>undef
    #++ to block the server unless a client wants to connect (is accep
+t()'ed).
    warn "Server: $!\n"; #++
  }#++


#--  close($new_sock);
}
[download]

HTH2

In reply to Re: IO::Socket Not responding after period of time and traffic! by Perlbotics
in thread IO::Socket Not responding after period of time and traffic! by aaronwroblewski

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:
	&		`&`
	<		`<`
	>		`>`
	[		`[`
	]		`]`

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.