Here is how a TCP connection gets established. Lets use port 80 for example. Client connects to server on port 80. Server accept conn and responds saying let's talk on port 12345. This is required so that the server can get rid of the client on port 80 to allow it to accept other connections on port 80 while still talking to the client. The end result is that the client-server interaction post the initial connection occurs on a Socket (Protocol/Port pair) that is to all intents and purposed known only to the client and server. There are therefore really only 2 widgets that can check the connection. The client software or the server software. The OS of course sees all connections but identifying the one you want external to the client-server socket is problematic. As noted the only way to truly validate the functionality of a connection is to send some data across the pipe and get the expected response.

I presume what you are saying is that you can't modify any of the client software, server software or firewall open ports. If this is correct you do have a problem but it can be solved easily enough, provided you can do SOMETHING on the system.

Although nowhere near as robust as passing real data down the socket you can probably check for the physical connectivity of the client. All you need to do is connect to it. Odds on your firewall will allow some external connections to remote ports. Find out which simply by doing a telnet remote.box port At this stage it can be any remote box that accepts connections on that port. Good ports to try are 25, 53, 80 and 110 as SMTP, DNS, HTTP and POP are integral to most systems. Once you have found a port that will pass through the firewall you can set a very simple server on the client - a simple perl server daemon that accepts a connection, prints OK and closes the conn would do. Then just get the server to query it as described and you will prove that the client is still out there.

You have not specified OS but if it is win32 you will find all sorts of open ports on any standard client. For example 25, 110, and 135 will probably accept connections on the client (GOK). This may save you installing anything on the client if it will already accept connections on some ports. Here is a trivial port scanner. If you ran it on the server and substituted 127.0.0.1 for the client address you may just luck out and find a port you can connect to on the client with no extra effort. Then just cron/at it with an appropriate messenger section:

use IO::Socket::INET;

for my $port ( 1..1024 ) {
    $sock = IO::Socket::INET->new(PeerAddr => '127.0.0.1',
                                 PeerPort => $port,
                                 Proto    => 'tcp',
                                 Timeout  => 2);
    print "Port $port ", $sock ? "OPEN\n" : "CLOSED\n";
    $sock->close if $sock;
}
[download]

---

---

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! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

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:
	&		&
	<		&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.