Socket Addresses

[Chris Torek]

In article <155 at sauron.OZ> shaun at sauron.UUCP (Shaun ARundell) writes:
>In have been working on a BSD4.3 ipc program ....  [Many] times
>I have seen a AF_UNIX address structure like
>
>struct sa {
>	short	family;
>	char	path[LARGE_NUMBER];
>};

Actually, it is

	struct sockaddr_un {
		short	sun_family;
		char	sun_path[108];
	};

and comes from <sys/un.h>.

>I take that this means that a socket address structure for AF_UNIX
>consists of a short (decribing the family) and as much data following
>that as you want.

Not quite: it is a short (specifying AF_UNIX) and a path name.
The name must be small enough to fit in an `mbuf' (a kernel data
object that has no business leaking restrictions into the Unix
namespace:  it was just expedient).  That is why there is a
107-character limit on the name.  (If you use all 108 bytes, you
will get EINVAL when you try to bind or connect.  This is more
expediency: the kernel null-terminates the name and passes it into
namei().)

>This would make sense. We all know (I think) that the socket system
>calls impose no address structure on the sockets but that different 
>families expect there addresses in a certin formats.

It is not *supposed* to impose a structure.  Ah well.

>NOW  - what can you say something like this
>
>server - 
>	s = socket(AF_UNIX,  SOCK_STREAM, 0);
>	...
>	bind(s, "server", sizeof( "server" ) );

No!  Try this instead:

	int s;
	struct sockaddr_un name;

	s = socket(AF_UNIX, SOCK_STREAM, 0);
	...
	name.sun_family = AF_UNIX;
	name.sun_name = "server";
	if (bind(s, (struct sockaddr *) &name, strlen(name.sun_name))) ...

Incidentally, as it says in the revised IPC primer, there is a
natural temptation to use

	struct sockaddr_un sun;

but this fails on a certain manufacturer's 68000-based systems. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu