|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Are named pipes quicker than just reading and writing to files?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 >But all of the implementations I've seen seem to just be writing and No, but the Win32 API lets you read and write to a number of resources>reading to a file. Is named pipes just a marketing term for regular >old file I/O. (such as sockets, ports and pipes) the same way you do with files. Mattias -- Mattias Sjögren [C# MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup. > But all of the implementations I've seen seem to just be writing and If you want to get deep enough, all computers talk in 1s and 0s. At the ends > reading to a file. Is named pipes just a marketing term for regular > old file I/O. 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 I would say no, unless it gives you something that you NEED (not just > be superior to just reading and writing to a file? desire). It is very maintainable to read and write files using classes in the Framework and not poking any deeper. -- Show quoteGregory A. Beamer MVP; MCP: +I, SE, SD, DBA ************************************************* Think outside of the box! ************************************************* <illegal.pr***@gmail.com> wrote in message news:1158723782.584269.284140@b28g2000cwb.googlegroups.com... > 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 >
Show quote
"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in But seriously. Is there any advantage to using a real IPC mechanism like message news:OSTK95L3GHA.3476@TK2MSFTNGP04.phx.gbl... >> 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. > 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  |
|||||||||||||||||||||||
Other interesting topics