sockets vs. STREAMS, also intermachine networking on SV
Dave Brower
daveb at gonzo.UUCP
Fri Feb 10 14:41:16 AEST 1989
In <11191 at ulysses.homer.nj.att.com> ekrell at hector.UUCP (Eduardo Krell) writes:
>In article <438 at laic.UUCP> scott at nova.laic.uucp (Scott Weitzenkamp) writes:
>
>>How does X11 (or X10 for that matter) use STREAMS?
>
>I think they use STREAMS pipes, which work like unix domain sockets.
While in <11196 at ulysses.homer.nj.att.com> smb at ulysses.homer.nj.att.com
(Steven M. Bellovin) quotes my question:
>
>In article <501 at gonzo.UUCP>, daveb at gonzo.UUCP (Dave Brower) writes:
>> (Actually, a /dev/spx "stream pipe" sometimes exists, but it is
>> undocumented and unsupported, I think. It also isn't bidirectional,
>> which is annoying).
>
>Yes it is bidirectional; however, it's only a half-pipe. More
>precisely, to create a stream pipe one has to open /dev/spx twice, and
>issue the I_FDINSERT on one file descriptor passing down the value of
>the second file descriptor. (Don't blame me, folks; I didn't invent
>/dev/spx or the ioctl.)
>
>In the distributed system, /dev/spx is mode 644, I believe; it's
>certainly not 666. I cannot vouch for the security of a system in which
>/dev/spx is made generally available; its primary (sole?) purpose is to
>support parts of RFS, and it's quite possible that the security of RFS
>could be compromised by such a change. On the other hand, I don't know
>that such a scenario is possible; I've never felt the urge to dig that
>deeply into RFS internals.
I take Steve's questions about permissions on /dev/spx seriously.
(Some vendors deliver it mode 600 to root, I think.) This makes me
wonder about Eduardo's comments about X. The main reason you want a
stream pipe is so you can use poll() in your server, which is supposed
to pay attention to a number of connected clients. Now SVR3 has no
generically supported method for doing this as far as I can tell.
/dev/spx can probably be coerced into working, but there seem to be
security implications. Is there a reasonable answer, or are we really
supposed to wait for SVR4?
I stand corrected by Steve and Doug Gwyn who also corrected my
understanding of /dev/spx bidirectionality. I will claim that lacking
any documentation (or a source license for the stuff) it is kind of hard
to tell!
Lacking documentation and source, can someone answer these questions
about /dev/spx? Imagine a server has opened /dev/spx, and arranged for
the creation of a device file for the returned minor device. Client
programs want to talk to the server by opening that device file.
1. What happens if two client programs try to open the same minor device?
Would they get a multiplexed channel with a server on the other end,
or would the second fail? (By comparison FIFO files multiplex, but
psuedo-tty's fail, I think).
2. If the server is sitting in a poll() on a stream pipe, and the client
on the other end dies, does the poll return or does it hang? If it
hangs, what can you do to recover?
3. What _does_ RFS use /dev/spx for? How does it arrange
rendevouz addresses?
Thanks,
-dB
--
If life was like the movies, the music would match the picture.
{sun,mtxinu,hoptoad}!rtech!gonzo!daveb daveb at gonzo.uucp
More information about the Comp.unix.questions
mailing list