Are named pipes quicker than just reading and writing to files?

[illegal.prime]

Hi all, I've been looking into doing some interprocess communication
and have been reading about named pipes. Everyone seems to indicate
that if the processes are either on your local PC or at least on your
local LAN AND your messages are reasonably small (under a kilobyte) -
then named pipes are the right solution.

But all of the implementations I've seen seem to just be writing and
reading to a file. Is named pipes just a marketing term for regular
old file I/O.

Here are the two implementations I've looked at:
http://www.codeproject.com/csharp/DotNetNamedPipesPart1.asp
http://i-d-e-a-s.blogspot.com/

I think the second URL provides a more concise implementation so that I
can more easily use the code myself in my own project. As opposed to
the first one - which while well architected in design all comes with
lots of classes, interfaces and even a prebuilt dll to which you don't
have the source.

Am I gaining anything by using the implementation in the second URL
over just using a regular write and read to and from a file? If not,
is there some inter-process code that is relatively concise that would
be superior to just reading and writing to a file?

Thanks,
Novice

 

[Mattias Sjögren]

But all of the implementations I've seen seem to just be writing and
reading to a file. Is named pipes just a marketing term for regular
old file I/O.

No, but the Win32 API lets you read and write to a number of resources
(such as sockets, ports and pipes) the same way you do with files.


Mattias

 

[Cowboy \(Gregory A. Beamer\)]

But all of the implementations I've seen seem to just be writing and

reading to a file. Is named pipes just a marketing term for regular
old file I/O.

If you want to get deep enough, all computers talk in 1s and 0s. At the ends
of each "conversation" there is a storage place (database, file, memory
location) and moving from one storage place to another is done via
streaming. If you get this deep, then pipes are simply regular I/O.

is there some inter-process code that is relatively concise that would
be superior to just reading and writing to a file?

I would say no, unless it gives you something that you NEED (not just
desire). It is very maintainable to read and write files using classes in
the Framework and not poking any deeper.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************

 

[Carl Daniel [VC++ MVP]]

If you want to get deep enough, all computers talk in 1s and 0s. At the
ends of each "conversation" there is a storage place (database, file,
memory location) and moving from one storage place to another is done via
streaming. If you get this deep, then pipes are simply regular I/O.


I would say no, unless it gives you something that you NEED (not just
desire). It is very maintainable to read and write files using classes in
the Framework and not poking any deeper.

But seriously. Is there any advantage to using a real IPC mechanism like
named pipes for IPC rather than using File I/O? Of course there is!

Most notably, named pipes provide queue-like behavior that's hard to get
using file I/O.

If all you need in an IPC mechanism is to pass some one-time information to
a child process that you create, then files are fine. If, however, the two
processes will engage in a "conversation", then files are singularly
inappropriate and difficult to use correctly. Instead, use named pipes, or
MSMQ, or SQL Server Notification Services, or sockets - almost anything will
be a better choice than file I/O.

-cd