[net.unix-wizards] UNIX domain sockets ?

lerner@isi-vaxa.arpa (Mitchell Lerner) (05/06/86)

>Does anyone have any information or experience regarding the general
>health of stream-mode, unix-domain sockets under Release 3.0 of SUN
>UNIX?  We are helping some folks port an application from a BSD 4.2
>VAX 750 to our SUN-3/160.  The application appears to run fine on the
>750, but on the SUN, the processes seem to have problems trying to
>rendevous at each others sockets.  Occasionally everyone comes up
>and all appears to run fine, but usually the rendevous fails.


Well, sombody correct me if i am wrong, but, when 4.2 first was released
Unix domain sockets were flakey, much in the way that you describe above.
I was told that Dr. Bill Joy himself said, somthing to the effect: "Unix
domain sockets were just not a good Idea." and " Dont use Unix domain because
It doesnt work.".

Even for Intrahost (same host) IPC I've used the Internet domain and had 
no problem.  The kernal can tell that the connection is not remote and 
doesnt send the data out the e.c/LAN (incurring overhead).

I'm not shure that this is what you wanted to know but ... for what it's
worth ...

mark@umcp-cs.UUCP (Mark Weiser) (05/08/86)

In article <596@brl-smoke.ARPA> lerner@isi-vaxa.arpa (Mitchell Lerner) writes:
>I was told that Dr. Bill Joy himself said, somthing to the effect: ...

Is B.J. a Dr. now?
-mark
-- 
Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

lerner@isi-vaxa.arpa (Mitchell Lerner) (05/09/86)

I've found it interesting that out of six responses to my jounal submittion,
six of them were responses only concerning if indeed bill joy has a Ph.D..  
hmmmmm, considering the size of his following and the current glamor of 
computing in the media, maybe this is good matieral for the National Star or 
the Enquirer? 

Bill, Are there any juicy tid-bits about your background that might interest
inquiring minds (like our's on the net)?  You might become the first computer
scientist to make the "Enquirer set" or Dell books.

"Unix domain sockets" could be a house-hold phrase just like "theory of general
relativity".

bbarnett@factron.uucp (Bruce Barnett) (05/12/86)

In article <596@brl-smoke.ARPA> lerner@isi-vaxa.arpa (Mitchell Lerner) writes:
>>Does anyone have any information or experience regarding the general
>>health of stream-mode, unix-domain sockets under Release 3.0 of SUN
>>UNIX?  
>Well, sombody correct me if i am wrong, but, when 4.2 first was released
>Unix domain sockets were flakey, much in the way that you describe above.
>I was told that Dr. Bill Joy himself said, somthing to the effect: "Unix
>domain sockets were just not a good Idea." and " Dont use Unix domain because
>It doesnt work.".
>
>Even for Intrahost (same host) IPC I've used the Internet domain and had 
>no problem.  The kernal can tell that the connection is not remote and 
>doesnt send the data out the e.c/LAN (incurring overhead).

Doesn't this work only if you run ifconfig(8)? Then, assuming  a stand-alone
machine, you either get an error `no carrier' every thirty seconds (or so) 
or you have to put a loop-back plug on the ethernet connecter on the back 
of the Sun.

My question is: Is there a single method of using sockets on both stand-alone
and networked machines? Or do we have to use two different portions of code
for the two configurations? How do people handle this difference?

As an aside, if Unix Domain sockets are so flakey, how do pipes (which are 
implemented as sockets) work without (apparent) problems?

Bruce Barnett (518) 783 3516

 seismo!rochester!steinmetz!factron!bbarnett
                       spar!factron!bbarnett

jas@rtech.UUCP (Jim Shankland) (05/12/86)

> Even for Intrahost (same host) IPC I've used the Internet domain and had 
> no problem.  The kernal [sic] can tell that the connection is not remote and 
> doesnt send the data out the e.c/LAN (incurring overhead).

(plus ca change...)
But I've recently had cause to discover that using the Internet domain
intra-host is still twice as slow as using the Unix domain, apparently
because at least some layers of the stream protocols are still being
used (checksumming, etc.).

Jim Shankland

 ihnp4!cpsc6a!\
               rtech!jas
ucbvax!mtxinu!/

jdb@mordor.ARPA (John Bruner) (05/15/86)

Aside from issues of speed, UNIX domain sockets provide a capability
(no pun intended) that Internet domain sockets do not.  It is possible
to pass file descriptors between processes using UNIX domain datagrams.
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor [jdb@s1-c.ARPA]	(415) 422-0758
  UUCP: ...!ucbvax!dual!mordor!jdb 	...!seismo!mordor!jdb

rbj@icst-cmr.arpa (Root Boy Jim) (05/19/86)

	Bill, Are there any juicy tid-bits about your background ...

Here is a haiku I found while looking thru /usr/src/ucb/ex/expreserve.c:

/*
 *	people making love
 *	never exactly the same
 *	just like a snowflake 
 */

You find things in the strangest places.

	(Root Boy) Jim Cottrell		<rbj@cmr>
	"One man gathers what another man spills"

brett@wjvax.UUCP (05/19/86)

In article <6928@mordor.ARPA> jdb@mordor.UUCP (John Bruner) writes:
>Aside from issues of speed, UNIX domain sockets provide a capability ...
>to pass file descriptors between processes using UNIX domain datagrams.

I am curious -- how?  In addition, I have a general question.  It looks to
me like the name to which a UNIX domain socket may be bound is limited to
13 or fewer characters (at least in our implementation - VAX 750, Mt Xinu
4.2 BSD) in the struct sockaddr structure.  UNIX domain socket names
are located in the filesystem, and this 13 character name length limit
seems severely to restrict where in the filesystem a socket name may reside.
How do other people manage this restriction?  Is there such a restriction?  If
so, where do people typically put socket names -- in /etc?

Please respond by E-Mail; I will summarize.  Thanks (in advance)

-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett