I've countless web searches and linux-kernel archives, but I haven't yet
found the answer to my question.
I'm porting some software to Linux that requires use of a bidirectional,
named pipe. The architecture is as follows: A server creates a named pipe
in the /tmp directory. Any client can then open("/tmp/pipename",
O_RDWR|O_NDELAY) and gain access to the server. The pipe is bidirectional,
so the client and server communicate on the same pipe. I support a number
of clients on the single pipe using file-locking to prohibit from two
clients from writing/reading at once.
How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
pipes are bidirectional, and I can attach a name with fattach(). In SVR3
Unices, I go through a bunch of hacking using the "stream clone device --
/dev/spx". I experiemented with socket-based pipes under Linux, but I
couldn't gain access to them by open()ing the name. Is there help? I
really don't want to use LiS (the Linux Streams) package, as I'd rather do
something native and not be dependent on another module. Plus, I read
somewhere that this was a poor way to do things.
Brendan
Please cc: me personally, as I am not subscribed.
Perhaps man 2 mkfifo ?
On 02.03 "Miller, Brendan" wrote:
>
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named pipe
> in the /tmp directory. Any client can then open("/tmp/pipename",
> O_RDWR|O_NDELAY) and gain access to the server. The pipe is bidirectional,
> so the client and server communicate on the same pipe. I support a number
> of clients on the single pipe using file-locking to prohibit from two
> clients from writing/reading at once.
>
> How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
> pipes are bidirectional, and I can attach a name with fattach(). In SVR3
> Unices, I go through a bunch of hacking using the "stream clone device --
> /dev/spx". I experiemented with socket-based pipes under Linux, but I
> couldn't gain access to them by open()ing the name. Is there help? I
> really don't want to use LiS (the Linux Streams) package, as I'd rather do
> something native and not be dependent on another module. Plus, I read
> somewhere that this was a poor way to do things.
>
> Brendan
>
> Please cc: me personally, as I am not subscribed.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more beer
Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
I thought mkfifo was only unidirectional...
Brendan
Please cc: me personally, as I am not subscribed.
-----Original Message-----
From: J . A . Magallon [mailto:[email protected]]
Sent: Friday, February 02, 2001 4:47 PM
To: Miller, Brendan
Cc: 'linux-kernel @ vger . kernel . org'
Subject: Re: bidirectional named pipe?
Perhaps man 2 mkfifo ?
On 02.03 "Miller, Brendan" wrote:
>
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named
pipe
> in the /tmp directory. Any client can then open("/tmp/pipename",
> O_RDWR|O_NDELAY) and gain access to the server. The pipe is
bidirectional,
> so the client and server communicate on the same pipe. I support a number
> of clients on the single pipe using file-locking to prohibit from two
> clients from writing/reading at once.
>
> How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
> pipes are bidirectional, and I can attach a name with fattach(). In SVR3
> Unices, I go through a bunch of hacking using the "stream clone device --
> /dev/spx". I experiemented with socket-based pipes under Linux, but I
> couldn't gain access to them by open()ing the name. Is there help? I
> really don't want to use LiS (the Linux Streams) package, as I'd rather do
> something native and not be dependent on another module. Plus, I read
> somewhere that this was a poor way to do things.
>
> Brendan
>
> Please cc: me personally, as I am not subscribed.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more
beer
Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
> I've countless web searches and linux-kernel archives, but I haven't yet
> found the answer to my question.
>
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named pipe
> in the /tmp directory. Any client can then open("/tmp/pipename",
> O_RDWR|O_NDELAY) and gain access to the server. The pipe is bidirectional,
> so the client and server communicate on the same pipe. I support a number
> of clients on the single pipe using file-locking to prohibit from two
> clients from writing/reading at once.
>
> How can I do this under Linux? In SVR4 Unices, I just use pipe() as it's
> pipes are bidirectional, and I can attach a name with fattach(). In SVR3
> Unices, I go through a bunch of hacking using the "stream clone device --
> /dev/spx". I experiemented with socket-based pipes under Linux, but I
> couldn't gain access to them by open()ing the name. Is there help? I
> really don't want to use LiS (the Linux Streams) package, as I'd rather do
> something native and not be dependent on another module. Plus, I read
> somewhere that this was a poor way to do things.
How about use a unix socket instead of a named pipe.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Many thanks to all who have suggested to use UNIX domain sockets. That was
my first thought--I just didn't know how to preserve the existing named
interface. And yes, I have consulted several "decent" UNIX programming
books which have led me to the likelihood that what I want to do cannot be
done under Linux. A shame, really, even if it is a travestible, abominable
way to do it.
The common, named pipe interface was a way to maintain compatibility with
legacy code of previous versions that are already out in the field. If I
change the architecture now, folks porting from UnixWare to Linux (for
example) will have to change their applications (maybe--I haven't fully
analyzed whether I can change the underlying behavior without affecting our
API) in order to use Linux.
I am aware that the current design may not be the most efficient, or even
the most portable, but I was hoping to maintain it for compatibility sake.
If someone wants to tell me how to do it, great. If not, I'll assume it
can't be done and start reworking everything to use socket() or
socketpair().
Thanks all,
Brendan
Please cc: me on all replies.
> I'm porting some software to Linux that requires use of a bidirectional,
> named pipe. The architecture is as follows: A server creates a named pipe
Pipes are not bidirectional in Linux. We follow traditional non stream
behaviour
> /dev/spx". I experiemented with socket-based pipes under Linux, but I
> couldn't gain access to them by open()ing the name. Is there help? I
AF_UNIX sockets are bidirectional but like all sockets use bind() and
connect().
Alan Cox wrote:
> > /dev/spx". I experiemented with socket-based pipes under Linux, but I
> > couldn't gain access to them by open()ing the name. Is there help? I
>
> AF_UNIX sockets are bidirectional but like all sockets use bind() and
> connect().
And that's because sockets don't behave like bidirectional fifos.
Each connection to a socket is a distinct stream.
-- Jamie
Alan Cox wrote:
>
> > I'm porting some software to Linux that requires use of a bidirectional,
> > named pipe. The architecture is as follows: A server creates a named pipe
>
> Pipes are not bidirectional in Linux. We follow traditional non stream
> behaviour
>
> > /dev/spx". I experiemented with socket-based pipes under Linux, but I
> > couldn't gain access to them by open()ing the name. Is there help? I
>
> AF_UNIX sockets are bidirectional but like all sockets use bind() and
> connect().
How hard would it be to add? The limitation on fifos that you get the same
one every time you open it makes some things tricky -- the server has to
move the fifo and mkfifo a new one to replace its data with something else,
for instance, which is not atomic.
I don't understand, in the original problem, how the server opens
the named bipipe differently from the servers, to be on one end rather than
the other.
A way to map a file name to a socket pair would be nice, the first to open
it could get one end of it and everyone else would get the other end, or there
would be a switch.
You could patch the file system code, I wonder how deep the changes would have
to be, if you did it in terms of lots of fifos.
Followup to: <[email protected]>
By author: "David L. Nicol" <[email protected]>
In newsgroup: linux.dev.kernel
>
> How hard would it be to add? The limitation on fifos that you get the same
> one every time you open it makes some things tricky -- the server has to
> move the fifo and mkfifo a new one to replace its data with something else,
> for instance, which is not atomic.
>
> I don't understand, in the original problem, how the server opens
> the named bipipe differently from the servers, to be on one end rather than
> the other.
>
> A way to map a file name to a socket pair would be nice, the first to open
> it could get one end of it and everyone else would get the other end, or there
> would be a switch.
>
> You could patch the file system code, I wonder how deep the changes would have
> to be, if you did it in terms of lots of fifos.
>
I would really like it if open() on a socket would be the same thing
to connect to a socket as a client. I don't think it's a good idea to
do that for the server side, though, since it would have to know about
accept() anyway.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
According to the Understanding the Linux Kernel book I
plowed through yesterday afternoon the EXT2 file system
has a defined file type "socket," distinct from fifo.
How does one set up a named socket in a file system? Is it
a legacy constant that has never been supported or what?
"David L. Nicol" wrote:
>
> Alan Cox wrote:
> >
> > > I'm porting some software to Linux that requires use of a bidirectional,
> > > named pipe. The architecture is as follows: A server creates a named pipe
> >
> > Pipes are not bidirectional in Linux. We follow traditional non stream
> > behaviour
> >
> > > /dev/spx". I experiemented with socket-based pipes under Linux, but I
> > > couldn't gain access to them by open()ing the name. Is there help? I
> >
> > AF_UNIX sockets are bidirectional but like all sockets use bind() and
> > connect().
> You could patch the file system code, I wonder how deep the changes would have
> to be, if you did it in terms of lots of fifos.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
--
David Nicol 816.235.1187 [email protected]
"I don't care how they do it in New York"
"David L. Nicol" <[email protected]> writes:
> According to the Understanding the Linux Kernel book I
> plowed through yesterday afternoon the EXT2 file system
> has a defined file type "socket," distinct from fifo.
>
> How does one set up a named socket in a file system? Is it
> a legacy constant that has never been supported or what?
>
Call bind() on an AF_LOCAL (aka AF_UNIX) socket.
About as far from legacy as you can get...
-Doug
On Thu, Feb 08, 2001 at 03:10:08PM -0800, H. Peter Anvin wrote:
I would really like it if open() on a socket would be the same
thing to connect to a socket as a client. I don't think it's a
good idea to do that for the server side, though, since it would
have to know about accept() anyway.
things like this (non-portable hacks) belong in libc surely?
--cw
Chris Wedgwood wrote:
>
> On Thu, Feb 08, 2001 at 03:10:08PM -0800, H. Peter Anvin wrote:
>
> I would really like it if open() on a socket would be the same
> thing to connect to a socket as a client. I don't think it's a
> good idea to do that for the server side, though, since it would
> have to know about accept() anyway.
>
> things like this (non-portable hacks) belong in libc surely?
>
Not if it makes more sense to implement in the kernel. I can't think of
a way to implement it in glibc without races, perhaps you can.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt