HP3000-L Archives

November 2001, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Sun, 25 Nov 2001 11:22:37 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
Jim writes:
> I am seeking help in using named pipes to function in the same way as
> message files

Unfortunately pipes/fifos are pretty useless as Message File replacements in
most cases.

Pipes are generally implemented as simply a small in-memory buffer with a file
system (open/close/read/write) interface.  If you write more data than will
fit in the buffer, you'll block until the reader reads some of the data.  You
can't specify an arbitrary size for a pipe as you can when :BUILDing a Message
File, since a pipe is not actually a file.

Message Files are record oriented, and so accept and deliver messages in nice
atomic chunks, whereas pipes are, like TCP, simply a stream of bytes which one
person adds bytes to and the other reads bytes from with no guarantees as to
what sized chunks the reader will see.

For instances of multiple writers, you'll probably need to have one pipe per
writer, and have the reader use select() and non-blocking I/O to manage things.

For any non-trivial application of Message Files, a better replacement would
probably be sockets, possibly using just the system local AF_UNIX variety that
don't involve the network (though if you use TCP based sockets then you also
get the ability to distribute your application across multiple machines for
free).

The sockets API provides much more control than the simple interfaces provided
by pipes.  Multiple writers can all ask to connect to the same port#, so you
don't have to make the writers coordinate over who is going to write to which
pipe, etc.

In all cases you'll still have the problem that the "pipe" can only contain a
limited amount of data, so any persistence or queuing capability will have to
be implemented manually, possibly in *both* the writer and reader code.

There are some commercial products like IBM's "MQ Series" asynchronous
messaging system that are designed to provide all of the queueing, routing,
and guaranteed delivery features required in applicaitons that involve passing
messages back and forth.

There could certainly be some free tools out there that let you do the same
sort of thing (Java probably has something for example), but I've not looked
into it.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2