[lug] Named pipe and network tool?

D. Stimits stimits at idcomm.com
Tue Jun 5 23:18:31 MDT 2001


Chris Riddoch wrote:
> 
> "D. Stimits" <stimits at idcomm.com> writes:
> >
> > Chris Riddoch wrote:
> > > pilot <-> pi-port <-network-> *** <-> named pipe <-> application (e.g. jpilot)
> >
> > One question...do you already have the "application" part that can
> > read/write from a named pipe?
> >
> 
> Yeah. Any program that reads and writes files doesn't care what *kind*
> of file it is, in most cases, as long as it's a file that can be read
> and written to.  (for the most part) Even 'cat' could do it.  It's The
> Unix Way(TM).  /dev/hda can be treated like a file, though you might
> not *want* to, you *could* use "grep" on /dev/hda.  (Naturally, there
> are usually better ways to handle certain tasks.  But it's possible!)

To be more specific, I do not have any kind of PDA. I was wondering if
you already have the application where this has been done:
"If the program were made to talk to a named pipe, though...".

It sounds like you might need both the PDA program that runs on TCP/IP
for the PDA, as well as a desktop Linux app that does the TCP/IP-to-pipe
function. The TCP/IP-to-pipe function would be somewhat trivial to
create (at least in some basic form that doesn't do much aside from
buffered copies...add in things like authentication or encryption and it
gets more complicated in a hurry).

> 
> To use a named pipe, you create it with mkfifo.  And then you write to
> it.  And then you read from it.  Except it's not really a file, it's
> just a little data sink, a form of IPC - Inter-Process Communication.

I'm familiar with it (along with shared memory, message queues,
semaphores, so on).

> 
> Maybe someone else could explain it better. Particularly the part
> about how it's not really a file.  Hmmm.
> 
> --
> Chris Riddoch         |  epistemological
> socket at peakpeak.com   |  humility

Pi-port...does this already have TCP/IP ability, such that the
intermediate program for the desktop could be created without ambiguous
standards or protocols? If you literally need only a dumb program to
copy to/from a named pipe via a fixed TCP/IP socket port, it can be done
quite easily...but it sounds like maybe there are other issues, such as
needing to adapt existing applications on top of creating the missing
link between port 4386 and the named pipe.

D. Stimits, stimits at idcomm.com



More information about the LUG mailing list