Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi,


I'm writing external application in Perl that connects to LMCE system over IO::Socket::INET tcp connection.

Sometimes it happens that other client closes tcp connection, but my app happily goes on, sending things to dead TCP socket.

What are proper ways to prevent such state and check if TCP port is alive or better said other client didn't close TCP connection ?

Thanks in advance,

regards,

Rob.
  • Comment on Howto check if TCP connection is alive ?

Replies are listed 'Best First'.
Re: Howto check if TCP connection is alive ?
by zentara (Cardinal) on Mar 22, 2008 at 13:57 UTC
    See Check if Socket is alive before send Between IO::Socket::INET's $sock->connected, or IO::Select's $sock->can_read and $sock->can_write, you ought to be able to put an "if (test){ } in your code. Which one is best depends on the exact structure of your code.

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: Howto check if TCP connection is alive ?
by derby (Abbot) on Mar 22, 2008 at 12:50 UTC

    You cannot reliably prevent the closing of a tcp connection (that's just the nature of tcp). Your app should be checking the return value of the send method (and I'm just guessing that's what you're using to write to the socket) and act/react accordingly.

    -derby
Re: Howto check if TCP connection is alive ?
by ikegami (Patriarch) on Mar 22, 2008 at 11:42 UTC
    Send something over it periodically. ( I meant something that would cause a reply to be returned. If you don't get the reply before a timeout, consider the socket dead. )
      Hi,

      thanks for response.. Sadly, this is not an option, cause server on the other side doesn't allow me to do that....

      I've read something about keep alive or something, but only in connection to C TCP sockets... There must be some other way to check this without sending on tcp or not ?

      Thanks in advance,

      regards,

      Rob.

        You should talk with the person supporting the server, then. The protocol for a reasonable Client and Server using TCP/IP would include heartbeats. (That is, if a Client hasn't received a message from the Server in M milliseconds, send a heartbeart. If the Server hasn't returned a Heartbeat Acknowledgement in N milliseconds, drop the connection and reconnect.)

        No, the server either needs to send you something periodically by design (a heatbeat), or you need to provoke it into sending something (by sending some request, even one for which you don't care about the answer).

        As an example of the latter, my FTP client sends "TYPE I", "PWD" and other useless commands from time to time. None of the following accomplishes anything except to let the server know we are still alive, and conversely, letting us know the server is still alive.

        COMMAND:> TYPE I 200 Type set to I COMMAND:> PWD 257 "/" is current directory. COMMAND:> TYPE A 200 Type set to A COMMAND:> PASV 227 Entering Passive Mode (69,163,167,32,177,6). COMMAND:> LIST STATUS:> Connecting ftp data socket 69.163.167.32:45318... 150 Opening ASCII mode data connection for file list 226 Transfer complete. COMMAND:> TYPE A 200 Type set to A COMMAND:> PWD 257 "/" is current directory. COMMAND:> REST 0 350 Restarting at 0. Send STORE or RETRIEVE to initiate transf +er COMMAND:> TYPE A 200 Type set to A COMMAND:> TYPE I 200 Type set to I