Date: Sat, 1 Mar 1997 12:12:21 PST From: "Marty Leisner" <leisner@sdsp.mc.xerox.com> To: <avalon@coombs.anu.edu.au> Cc: Darren Reed <avalon@coombs.anu.edu.au>, julian@whistle.com (Julian Elischer), matt@lkg.dec.com, terry@lambert.org, hackers@freebsd.org Subject: Re: Alternatives to SYSV IPC? Message-ID: <9703012012.AA23110@gnu.sdsp.mc.xerox.com> In-Reply-To: Your message of "Wed, 26 Feb 1997 13:07:42 PST." <9702262107.AA16436@gnu.sdsp.mc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <9702262107.AA16436@gnu.sdsp.mc.xerox.com>, you write: >> In some mail from Julian Elischer, sie said: >> > >> > > if (socketpair(AF_UNIX, SOCK_STREAM, 0, fds) < 0) >> > > perror("socketpair"); >> > >> > how come no-one uses AF_LOCAL with SOCK_DGRAM? >> >> how portable is AF_LOCAL ? >> >> Darren > >Is AF_LOCAL/SOCK_DGRAM posix 1003.1g? > In socket, you should use PF_* (protocol family). In bind or sendto, you use the AF_*(address family). Posix 1003.1g changed it from _UNIX to _LOCAL. (methinks). This is the explanation by Dan Lanciani (from http://www.noao.edu/~rstevens/lanciani.96apr10.txt Article: 49920 of comp.protocols.tcp-ip From: ddl@harvard.edu (Dan Lanciani) Newsgroups: comp.protocols.tcp-ip Subject: Re: sockets: AF_INET vs. PF_INET Message-ID: <3561@news.IPSWITCH.COM> Date: 10 Apr 96 01:27:20 GMT In article <3169B256.41C6@engr.sgi.com>, sam@engr.sgi.com (Sam Leffler) writes: | Dan Lanciani wrote: |> |> In article <4k1grt$5gq@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes: |> | > So why the difference? |> | > AF vs PF? |> | > What does the difference mean? |> | |> | AF = address family. These constants go into the sin_family member of the |> | socket address structure. |> | |> | PF = protocol family. These constants are the first argument to socket(). |> |> There is a little more to it than that. Although I don't have the ancient |> sources handy to check (and my memory of this particular aspect is fading), |> I recall that the original socket code (4.1c/2.8/2.9BSD) employed a protocol |> structure similar in concept to the sockaddr structure. The protocol |> structure contained a family element and a family-specific protocol number. |> The PF_ constants were used for the family element of the protocol structure. |> A protocol structure (or, rather, the address of one) could be passed to the |> socket() call to serve a purpose similar to that of the last (integer) |> argument |> of the current socket() call. (Keep in mind that the old socket() call did |> not |> take a family/domain argument at all, so interpretation of the protocol |> number |> would not have been possible without the PF_ cue.) Originally, then, the PF_ |> and AF_ constants had a much more parallel purpose as structure tags. When |> socket() started requiring a family/domain argument, the protocol structure |> was dropped. | | Well, actually your memory is a bit off. While that may well be true in general, I was correct on this issue. :) | The original socket design included | a concept termed a "communications domain" (or "communication domain", never | could decide which was correct :-)). A domain encapsulated many aspects of | communication including the protocol family and address format. Sockets were | to be created "within a domain" and carried with them the semantics of the | domain. This was originally to be carried out using a domain() system call | that | returned a descriptor that was then passed as the first argument to socket(). The above may describe the original *concept*, but it was not the implementation in 4.1c/2.9BSD. Whether what you describe ever existed in an implementation, I can't say. I do remember that early 4.2 manuals described all sorts of neat IPC mechanisms that did not exist in the operating system. Something about ``portals'' comes to mind. | Along the way we decided this was not worthwhile and replaced the descriptor | with a manifest constant (PF_*) that referenced a fixed set of domains with | the associated semantics. No, the evolution really did include the version I described. It did not jump from the (hypothetical?) domain() semantics to the current state. Here is an excerpt from the socket() man page of old: ----------------------------------------------------------------------------- SOCKET(2X) UNIX Programmer's Manual SOCKET(2X) NAME socket - create an endpoint for communication SYNOPSIS #include <sys/socket.h> s = socket(type, pf, addr, options); int type; struct sockproto *pf; struct sockaddr *addr; int options; ----------------------------------------------------------------------------- The type is what you would expect. The pf is the object of interest. The addr was used in place of a separate bind() and the options argument encoded bits similar to those used in current setsockopt() calls (plus the important SO_ACCEPTCONN which pre-dated listen()). Here is the interesting section from sys/socket.h: ----------------------------------------------------------------------------- struct sockproto { short sp_family; /* protocol family */ short sp_protocol; /* protocol within family */ }; #define PF_UNSPEC 0 /* unspecified */ #define PF_UNIX 1 /* UNIX internal protocol */ #define PF_INET 2 /* internetwork: UDP, TCP, etc. */ #define PF_IMPLINK 3 /* imp link protocols */ #define PF_PUP 4 /* pup protocols: e.g. BSP */ #define PF_CHAOS 5 /* mit CHAOS protocols */ #define PF_OISCP 6 /* ois communication protocols */ #define PF_NBS 7 /* nbs protocols */ #define PF_ECMA 8 /* european computer manufacturers */ #define PF_DATAKIT 9 /* datakit protocols */ #define PF_CCITT 10 /* CCITT protocols, X.25 etc */ ----------------------------------------------------------------------------- I programmed to these interfaces extensively; I assure you they were/are real. [...] |> Now, I would argue that the AF_ family is the correct set of constants |> for the first argument of socket(). My reason is simply that the constants |> in the tables in the socket code itself are AF_ values, and the first |> argument |> of socket() is compared to these to find the correct domain structure for |> the request. | | The correct parameter is a PF_foo. Why? | In practice however AF_foo = PF_foo and | at this point any implementation that does not maintain this will break lots |of code. FWIW my fingers automatically type AF_ when making a socket call :-). Good, you are doing the right thing. :) Dan Lanciani ddl@harvard.*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9703012012.AA23110>