#!/usr/bin/perl -w
# The client

use Socket;
use strict;
my ($socky, $line);

$socky = shift || '/tmp/mysock';
socket(SOCK, PF_UNIX, SOCK_STREAM, 0)  || die "socket: $!";
connect(SOCK, sockaddr_un($socky))     || die "connect: $!";

while (defined($line = <SOCK>)) {
    print $line;
}

exit;

#################
#!/usr/bin/perl -wT
# The server

use Socket;
use strict;
use Carp;

BEGIN { 
    $ENV{PATH} = '/usr/ucb:/bin';
}

sub logit { 
    print "$0 $$: @_ at ", scalar localtime, "\n";
}

my $NAME = '/tmp/mysock';
my $uaddr = sockaddr_un($NAME);
my $proto = getprotobyname('tcp');

socket(Server,PF_UNIX,SOCK_STREAM,0)        || die "socket: $!";
unlink($NAME);
bind  (Server, $uaddr)                      || die "bind: $!";
listen(Server,SOMAXCONN)                    || die "listen: $!";

logit "server started on $NAME";

my $waitedpid;

sub REAPER {
    $waitedpid = wait;
    $SIG{CHLD} = \&REAPER;
    logit "reaped $waitedpid" . ($? ? " with exit $?" : '');
}

$SIG{CHLD} = \&REAPER;

for ($waitedpid = 0;
     accept(Client,Server) || $waitedpid;
     $waitedpid = 0, close Client) {
    next if $waitedpid;
    logit "connection on $NAME";

    spawn sub {
        print "Hello there, it's now ", scalar localtime, "\n";
                exec '/usr/games/fortune' or die "can't exec fortune: 
+$!";
         };
}
[download]

Ahh, this uses the ugly %SIG-handler code that breaks servers sooner or later. There are better ways to reap kids. I have a few samples in my columns. Best look for examples that use a no-wait waitpid at strategic points in the top-level loop.

-- Randal L. Schwartz, Perl hacker

Okay, responding point by point:

A) I need to accomplish this interaction for a current project

The two modules are available today. I show many examples of their usage in my WT columns, as do many other tutorials.

B) I want to understand the details so I can be the one writing the modules one day

Good, then you'll want to study good code that does useful things. The source to these modules is well documented and less buggy than almost anything else you'll see on the net. So use the modules, then trace down inside to see what they're doing.

Do not attempt to build new technology without understanding existing technology. Reinventing the wheel is fine as long as you don't do it ignorantly.

-- Randal L. Schwartz, Perl hacker

That's true, examining the code may wield some useful stuff. By point A I wasn't implying that the modules weren't available, I was just describing how the need to get it done was only half my motivation, next to the need to understand. Turn, turn, turn.

Alan "Hot Pastrami" Bellows
-Sitting calmly with scissors-

It comes with a simple example of a calculator server which is a few dozen lines of perl. You might prefer this to merlyn's solution as it is probably lower overhead. Less buzzword friendly though ;-)

TIMTOWDI/YMMV/IMHO/ETC

-- Randal L. Schwartz, Perl hacker

Generally, however, if you want to limit your process's interaction to processes running on the local machine, you should consider Unix domain sockets, which work a lot like Internet sockets, but you listen on a special file, and have your other process "connect" to this file.

Both of these options have the added benefit/drawback of being able to serve any type of client that wants to interact with your "server" script, including clients that don't have any business doing this. If this is a problem, you may want to look into shared memory pools or pipes.

The perlipc man page has some great example code.