Unix-Domain TCP Clients and Servers

- Unix-Domain TCP Clients and Servers

## Unix-Domain TCP Clients and Servers

That's fine for Internet-domain clients and servers, but what about local communications? While you can use the same setup, sometimes you don't want to. Unix-domain sockets are local to the current host, and are often used internally to implement pipes. Unlike Internet domain sockets, Unix domain sockets can show up in the file system with an `ls(1)` listing.

        % ls -l /dev/log
        srw-rw-rw-  1 root            0 Oct 31 07:23 /dev/log

You can test for these with Perl's -S file test:

        unless ( -S '/dev/log' ) {
            die "something's wicked with the log system";
        }

Here's a sample Unix-domain client:

        #!/usr/bin/perl -w
        use Socket;
        use strict;
        my ($rendezvous, $line);

        $rendezvous = shift || 'catsock';
        socket(SOCK, PF_UNIX, SOCK_STREAM, 0)       || die "socket: $!";
        connect(SOCK, sockaddr_un($rendezvous))     || die "connect: $!";
        while (defined($line = <SOCK>)) {
            print $line;
        }
        exit;

And here's a corresponding server. You don't have to worry about silly network terminators here because Unix domain sockets are guaranteed to be on the localhost, and thus everything works right.

        #!/usr/bin/perl -Tw
        use strict;
        use Socket;
        use Carp;

        BEGIN { $ENV{PATH} = '/usr/ucb:/bin' }
        sub spawn;  # forward declaration
        sub logmsg { print "$0 $$: @_ at ", scalar localtime, "\n" }

        my $NAME = 'catsock';
        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: $!";

        logmsg "server started on $NAME";

        my $waitedpid;

        use POSIX ":sys_wait_h";
        sub REAPER {
            my $child;
            while (($waitedpid = waitpid(-1,WNOHANG)) > 0) {
                logmsg "reaped $waitedpid" . ($? ? " with exit $?" : '');
            }
            $SIG{CHLD} = \&REAPER;  # loathe sysV
        }

        $SIG{CHLD} = \&REAPER;

        for ( $waitedpid = 0;
              accept(Client,Server) || $waitedpid;
              $waitedpid = 0, close Client)
        {
            next if $waitedpid;
            logmsg "connection on $NAME";
            spawn sub {
                print "Hello there, it's now ", scalar localtime, "\n";
                exec '/usr/games/fortune' or die "can't exec fortune: $!";
            };
        }

        sub spawn {
            my $coderef = shift;

            unless (@_ == 0 && $coderef && ref($coderef) eq 'CODE') {
                confess "usage: spawn CODEREF";
            }

            my $pid;
            if (!defined($pid = fork)) {
                logmsg "cannot fork: $!";
                return;
            } elsif ($pid) {
                logmsg "begat $pid";
                return; # I'm the parent
            }
            # else I'm the child -- go spawn

            open(STDIN,  "<&Client")   || die "can't dup client to stdin";
            open(STDOUT, ">&Client")   || die "can't dup client to stdout";
            ## open(STDERR, ">&STDOUT") || die "can't dup stdout to stderr";
            exit &$coderef();
        }

As you see, it's remarkably similar to the Internet domain TCP server, so much so, in fact, that we've omitted several duplicate functions--spawn(), logmsg(), ctime(), and REAPER()--which are exactly the same as in the other server.

So why would you ever want to use a Unix domain socket instead of a simpler named pipe? Because a named pipe doesn't give you sessions. You can't tell one process's data from another's. With socket programming, you get a separate session for each client: that's why `accept()` takes two arguments.

For example, let's say that you have a long running database server daemon that you want folks from the World Wide Web to be able to access, but only if they go through a CGI interface. You'd have a small, simple CGI program that does whatever checks and logging you feel like, and then acts as a Unix-domain client and connects to your private server.

- Back to Internet TCP Clients and Servers in the perlipc manpage

- Forward to TCP Clients with IO::Socket in the perlipc manpage

- Up to the perlipc manpage

Unix-Domain TCP Clients and Servers