Perl Cd Bookshelf [Electronic resources] نسخه متنی

16.11.1. Problem

Use named pipes. First create one, probably from your shell:

% mkfifo /path/to/named.pipe

Here's a reader for it:

open($fifo, "<", "/path/to/named.pipe") or die $!;
while (<$fifo>) {
print "Got: $_";
}
close $fifo;

Here's a writer for it:

open($fifo, ">", "/path/to/named.pipe") or die $!;
print $fifo "Smoke this.\n";
close $fifo;

A named pipe, or FIFO as they are also known, is a special file that
acts as a buffer to connect processes on the same machine. Ordinary
pipes also allow processes to communicate, but those processes must
have inherited the filehandles from their parents. To use a named
pipe, a process need know only the named pipe's filename. In most
cases, processes don't even need to be aware that they're reading
from a FIFO.

Unfortunately, this won't always work, because some
finger programs and their attendant daemons
check the size of the .plan file before trying
to read it. Because named pipes appear as special files of zero size
on the filesystem, such clients and servers will not try to open or
read from our named pipe, and the trick will fail.

In our .plan example, the writer was a daemon.
It's not uncommon for readers to be daemons as well. Take, for
instance, the use of a named pipe to centralize logging from many
processes. The log server reads log messages from the named pipe and
can send them to a database or file. Clients write their messages to
the named pipe. This removes the distribution logic from the clients,
making changes to message distribution easy to implement.

This program is more complicated than the .plan
program for several reasons. First and foremost, we don't want our
logging server to block would-be writers for long. It's easy to
imagine a situation where an attacker or misbehaving writer opens the
named pipe for writing, but doesn't send a complete message. To
prevent this, we use alarm and
SIGALRM to signal us if we get stuck reading.

Only two exceptional conditions can happen when using named pipes: a
writer can have its reader disappear, or vice versa. If a process is
reading from a named pipe and the writer closes its end, the reading
process will get an end-of-file (<> returns
undef). If the reader closes the connection,
though, the writer will get a SIGPIPE when it next
tries to write there. If you disregard broken pipe signals with
$SIG{PIPE} =
'IGNORE', your print will
return a false value and $! will be set to
EPIPE:

use POSIX qw(:errno_h);
$SIG{PIPE} = 'IGNORE';
# ...
$status = print $fifo "Are you there?\n";
if (!$status && $! = = EPIPE) {
warn "My reader has forsaken me!\n";
next;
}

You may be asking "If I have 100 processes all trying simultaneously
to write to this server, how can I be sure that I'll get 100 separate
entries and not a jumbled mishmash with characters or lines from
different processes?" That's a good question. The POSIX standard says
that writes of less than PIPE_BUF bytes in size
will be delivered atomically, i.e., not jumbled. You can get the
PIPE_BUF constant from POSIX:

use POSIX;
print PIPE_BUF, "\n";

Fortunately, the POSIX standard also requires
PIPE_BUF to be at least 512
bytes. This means that all we have to do is ensure that our clients
don't try to log more than 512 bytes at a time.

What if you want to log more than 512 bytes at a time? Then you split
each large message into several smaller (fewer than 512 bytes)
messages, preface each with the unique client identifier (process ID,
say), and have the server reassemble them. This is similar to the
processing involved in TCP/IP message fragmentation and reassembly.

Because a single named pipe doesn't allow bidirectional access
between writer and reader, authentication and similar ways of
preventing forged messages are hard to do (if not impossible). Rather
than struggle to force such things on top of a model that doesn't
accommodate them, you are better off using the filesystem's access
control to restrict access to the file through the owner and group
permissions on the named pipe.