test1.pl:
use IO::Socket::INET;
my $out = new IO::Socket::INET(Proto => "udp", PeerAddr => "localhost"
+, PeerPort => 3000, Timeout => 10) || die "failed";
my $in = new IO::Socket::INET(Proto => "udp", LocalAddr => "localhost"
+, LocalPort => 3001, Timeout => 10) || die "failed";
print $out "1\n";
while (1) {
    my $msg = <$in>;
    chomp $msg;
    print "got $msg\n";
    print $out $msg + 1, "\n";
}

test2.pl:
use IO::Socket::INET;
my $in = new IO::Socket::INET(Proto => "udp", LocalAddr => "localhost"
+, LocalPort => 3000, Timeout => 10) || die "failed";
my $out = new IO::Socket::INET(Proto => "udp", PeerAddr => "localhost"
+, PeerPort => 3001, Timeout => 10) || die "failed";
while (1) {
    my $msg = <$in>;
    chomp $msg;
    print "got $msg\n";
    print $out $msg + 1, "\n";
    sleep 1;
}
[download]

test1.pl:
use IO::Socket::INET;
my $socket = new IO::Socket::INET(Proto => "udp", 
                               LocalAddr => "localhost",
                               LocalPort => 3000,
                               PeerAddr => "localhost", 
                               PeerPort => 3001, 
                               Timeout => 10) 
        || die "failed";
while (1) {
    my $msg = <$socket>;
    chomp $msg;
    print "got $msg\n";
    print $socket $msg + 1, "\n";
}

test2.pl:
use IO::Socket::INET;
my $socket = new IO::Socket::INET(Proto => "udp", 
                               LocalAddr => "localhost",
                               LocalPort => 3001,
                               PeerAddr => "localhost", 
                               PeerPort => 3000, 
                               Timeout => 10) 
        || die "failed";
print $socket "1\n";
while (1) {
    my $msg = <$socket>;
    chomp $msg;
    print "got $msg\n";
    print $socket $msg + 1, "\n";
}
[download]

I have a few notes, I'll be not too rigorous in terminology anyway:

• client/server and peer-to-peer means nothing at the transport layer (broadly speaking: the layer in the "IP stack" where TCP and UDP are): it's a concept related to the application layer;
• there are client/server application protocols that are UDP based, for example the DNS protocol works over UDP (and is able to switch to TCP when query responses don't fit into an UDP packet).

Maybe you are trying to say is that the concept of connection is meaningless in UDP: packets that flow from a client to a server and those that flow in the opposite direction are, in some way, unrelated. I mean: in a TCP connection a channel is established and a client and a server communicate over that channel; in UDP a client sends a "message" to a server and closes, and the server sends a "message" to a client and closes: no complicated checks, no connections.

Ciao!
--bronto

---

The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
--John M. Dlugosz

Yes, that’s what I mean. and thanks for adding the detail explanation ;-)

I even checked RFC 793, and through out the spec, they never used the notion of client/server. I should use those tech terms more carefully, and use them according to their conventional meanings ;-)

Thank you all very much for your replies!

I have looked over ActivePerl window quirks, things that don't work, etc. I didn't find anything mentioning socket behaviour (seems forking was a concern, but now "works").

What I'm looking for is something telling me that when two processes are operating on the same socket object, one will block the other (but I can't find that statement). BUT ONLY if you are using ActivePerl (ie. unix/linux is capable of operating on the same object in a forked process).

I understand the concept of the transport layer and am looking for a script that can monitor a port for incoming datagrams and -ALSO- listen to STDIN for user input (think: UDP chat...). Implementing a canned reply in the "recv" functionality works fine, but I'm looking to have the user provide the reply to the incoming datagram..

I hope this clarifies what I'm looking to do. And I hope there is atleast one way to do this with ActivePerl. :)

pg is on the right track when he says to use two sockets. You don't want to use the same socket to both send and receive over UDP. The code from the cookbook is for TCP sockets and won't work with UDP. If you want to use UDP, here is your code changed to use two sockets:

#!/usr/bin/perl
# biclient - bidirectional forking client   perl_book\cookbook\ch17_11
+.htm
use IO::Socket;
use English;
use strict;

my ($lport, $host, $port, $kidpid, $sock, $line, $msg, $MAXLEN);
$MAXLEN = 1024;
$|++;

unless (@ARGV == 3) { die "usage: $0 listen_port dest_host  dest_port\
+n" }
($lport, $host, $port) = @ARGV;

# create a udp connection to the specified host and port
my $in = IO::Socket::INET->new(Proto     => "udp",
                              LocalPort => $lport )
       or die "can't connect to port $lport on localhost: $!";

my $out = IO::Socket::INET->new(Proto     => "udp",
                              PeerAddr  => $host,
                              PeerPort  => $port)
       or die "can't connect to port $port on $host: $!";


print STDOUT "[Listening on $lport, Connected to ($host:$port)]\n";
# Thelonius notes: Actually, with UDP, we 
# are NOT CONNECTED to ($host:$port).
#  However, our messages will be sent there

# split the program into two processes, identical twins
die "can't fork: $!" unless defined($kidpid = fork());

if ($kidpid) {
    print STDOUT "Parent $PID started\n";

    # parent copies the socket to standard output
    while ($in->recv($msg, $MAXLEN)) {
        print "\nReceived from ($host:$port) \"$msg\" \n";
    # Thelonius notes: You do not know where
    # the message came from unless you use
    # recvfrom.
    }
    # This loop will never exit.
    kill("TERM" => $kidpid);        # send SIGTERM to child

} else {
    print STDOUT "Child $PID started\n";
    print $out "Child $PID started";

    # child copies standard input to the socket
    while ($line = <STDIN>) {
        chomp($line);  #print STDOUT "You entered: $line\n";
        print $out $line;
    }
    # You might want to kill parent if you exit.
}
exit;
[download]

My light has now flickered a bit, and I better understand that I am looking for communicating with a peer - not a true connection. Sorry it took me so long to grasp that concept..

So, to get my chat to work Thelonius was right. Two sockets is the way to go - but I the thing I was missing was that the "write" socket can be anything (ie. kernal picked) - as long as my peer gets to know where I'm listening (socket), we can establish a bidirectional channel..

Now my next step is to make my listening socket fork a child for each new peer.. And then I'll be set! I'll only define a listening socket from @ARGV, and in the children learn the peer listening socket from the initial message (or disregard the message..) from peer.