Xref: utzoo comp.unix.wizards:14610 comp.unix.questions:11616
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ukma!tut.cis.ohio-state.edu!ucbvax!mtxinu!rtech!gonzo!daveb
From: daveb@gonzo.UUCP (Dave Brower)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: sockets vs. STREAMS, also intermachine networking on SV
Keywords: I'm even more confused now...
Message-ID: <506@gonzo.UUCP>
Date: 10 Feb 89 04:41:16 GMT
References: <438@laic.UUCP> <11191@ulysses.homer.nj.att.com> <11196@ulysses.homer.nj.att.com>
Reply-To: daveb@gonzo.UUCP (Dave Brower)
Distribution: usa
Organization: Gonzo Media Group
Lines: 68

In <11191@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes:
>In article <438@laic.UUCP> scott@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@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com 
(Steven M. Bellovin) quotes my question:
>
>In article <501@gonzo.UUCP>, daveb@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@gonzo.uucp