Networking with IO::Socket

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

I need to detect but not interfere with a network port.

In short I want a script that listens on port 2000 in tandem with another application. This script will trigger a batch file when the port is active. What is happening now is when this script runs it blocks the other app. Any wisdom is welcome.

My current attempt:

use warnings;
# use strict;
use IO::Socket;
use Socket;

my $port = shift || 2000;

my $socket = IO::Socket::INET->new(
   LocalPort    => $port,
   Type         => SOCK_STREAM,
   Reuse        => 1,
   Listen       => 10,
)
   or die "Couldn't create server: $@\n";

while (my $client = $socket->accept()) {
   my ($port, $iaddr) = unpack_sockaddr_in($client->peername());

    #### GET TIME ####
    $t = time();
    my $then = localtime($t);  
    
    #### GET IP ####
    my $ip_address = inet_ntoa($iaddr); 

    open(PLOT,">>label-log.txt") || die("This file will not open!");
        seek PLOT,0,2;
        print PLOT "$ip_address $then \n";
    close(PLOT);

    sleep(5);
    system ("start /b C:\\momlabels\\transfer.bat");

   $client->send(inet_ntoa($iaddr));
   $client->close();

}
[download]

Comment on Networking with IO::Socket Download Code

Replies are listed 'Best First'.
Re: Networking with IO::Socket by stevieb (Canon) on Nov 30, 2015 at 01:31 UTC
Layer-4 (ie. the Transport Layer) of the IP stack doesn't work that way. You can NOT have two services listening on the same protocol/port at the same time, period. Switching your solution to use the opposite protocol (UDP:2000 vs. TCP:2000) will work fine, but UDP is session-less (which doesn't appear what you want). Either change your protocol or port, or change the existing service to listen on a different protocol/port. There is no other way around this, unless you wrap the other service with your script, and have it decipher what traffic is meant for you, or the wrapped service (and if it's for the wrapped service, you need to redirect the traffic along, effectively becoming a filter). This is just the way this portion of the network communication stack works. -stevieb	[reply]
Re^2: Networking with IO::Socket by NetWallah (Canon) on Nov 30, 2015 at 01:59 UTC
You can NOT have two services listening on the same protocol/port at the same time, period. There is a small loophole to that - the actual restriction is: You can NOT have two services listening on the same protocol/port at the same time at the same IP address. So - one possible workaround would be to listen ad different IP addresses, forwarding from one to the other. There is a discussion of somewhat less clunky solutions, mirroring traffic from one port to another at: http://stackoverflow.com/questions/7247668/duplicate-tcp-traffic-with-a-proxy. Our business is run on trust. We trust you will pay in advance.	[reply]
Re^3: Networking with IO::Socket by stevieb (Canon) on Nov 30, 2015 at 02:51 UTC
D'oh! Very, very good point :) I'm ashamed I missed it. Good job pointing it out.	[reply]
Re: Networking with IO::Socket by TheVend (Novice) on Nov 30, 2015 at 21:16 UTC
So then how would one accept incoming 192.168.0.10:2000(tcp) then direct to 127.0.0.1:2000(tcp) I think If i can accomplish this then i will be set!	[reply]
Re^2: Networking with IO::Socket by Apero (Scribe) on Nov 30, 2015 at 22:01 UTC
This is not something you normally do. If you want the application to be listening on 192.168.0.10:2000, then bind your program to that IP+port tupple. Unconditionally forwarding like you propose buys you nothing and will slow down the flow of data as it has to go through another userland application (ie: your software proxy.) Most OSes provide a NAT function (such as with PF under BSD or Netfilter under Linux), but here again, why waste kernel resources translating IPs instead of just putting your application on the IP you intend to listen for connections on? RFC1918 and IPv6 space is abundant, so it's a matter of needing a 2nd address, just assign one and bind to that. If you still think you need to do what you propose, maybe you can elaborate on what you're attempting to do? This feels like a case of trying to fit a square-peg in a round-hole. Now that I've (hopefully) talked you out of writing, or even using, a software proxy to talk to your own host, I'll give you some hints that socket code can get tricky. You need to worry about what I/O blocking mode you use, how to deal with partial reads and writes, what to do when one side performs a half-close (send EOF on a socket stream,) and similar complexities. Writing good socket-code generally requires a decent understanding of how the protocols work, plus programmatic concepts like buffers, polling, plus some design decisions when dealing with a bi-directional socket on each end. That last part could mean you juggle 4 I/O flows (in+out from the sender, and in+out to the receiver,) or that you go to a forked or threaded model where each process handles the flow in a single direction across the proxy's pipe. If you want to get more serious about socket code, I can recommend the UNPv1 book as an excellent place to start. The examples it has are in C, although the concepts are very usable in Perl (though reading the book's code examples really requires at least a basic understanding of C.)	[reply]
Re^3: Networking with IO::Socket by stevieb (Canon) on Dec 01, 2015 at 00:33 UTC
nginx can definitely do this and divide/redirect traffic by conditions specified all the way up to the application layer (as a 'reverse' proxy). However, I'm feeling this is an XY Problem, and that OP really doesn't want to be writing their own 'filter' or 'proxy'. Furthermore, it doesn't seem OP has the hardware resources (nor the financial resources or C-level backing) to do things properly. Perhaps if OP would state a bit more about their infrastructure, traffic patterns (how does traffic arrive to the box), DNS setup (from the external and internal sides) and what they're trying to achieve overall, the network people here may be able to help them come up with a solution that isn't overly insecure, and doesn't compromise traffic destined for other services. You do not want to promise something that you can't deliver, especially in an environment where you've got no backing whatsoever to make it so.	[reply]