BSD 4_4 release
[unix-history] / usr / src / share / doc / psd / 21.ipc / 3.t
index 830c544..0d429cf 100644 (file)
@@ -1,10 +1,37 @@
-.\" Copyright (c) 1986 Regents of the University of California.
-.\" All rights reserved.  The Berkeley software License Agreement
-.\" specifies the terms and conditions for redistribution.
+.\" Copyright (c) 1986, 1993
+.\"    The Regents of the University of California.  All rights reserved.
 .\"
 .\"
-.\"    @(#)3.t 1.2 (Berkeley) %G%
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"    This product includes software developed by the University of
+.\"    California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
 .\"
 .\"
-.ds RH "Network Library Routines
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"    @(#)3.t 8.1 (Berkeley) 6/8/93
+.\"
+.\".ds RH "Network Library Routines
 .bp
 .nr H1 3
 .nr H2 0
 .bp
 .nr H1 3
 .nr H2 0
@@ -23,9 +50,10 @@ interprocess communication facilities in a distributed
 environment.  To aid in this task a number of routines
 have been added to the standard C run-time library.
 In this section we will consider the new routines provided
 environment.  To aid in this task a number of routines
 have been added to the standard C run-time library.
 In this section we will consider the new routines provided
-to manipulate network addresses.  While the 4.3BSD networking
-facilities support both the DARPA standard Internet protocols
-and the Xerox NS protocols, most of the routines presented
+to manipulate network addresses.  While the 4.4BSD networking
+facilities support the Internet protocols
+and the Xerox NS protocols,
+most of the routines presented
 in this section do not apply to the NS domain.  Unless otherwise
 stated, it should be assumed that the routines presented in this
 section do not apply to the NS domain.
 in this section do not apply to the NS domain.  Unless otherwise
 stated, it should be assumed that the routines presented in this
 section do not apply to the NS domain.
@@ -91,52 +119,14 @@ and is defined to be the first address in the list of addresses
 in the \fIhostent\fP structure.
 .PP
 The database for these calls is provided either by the
 in the \fIhostent\fP structure.
 .PP
 The database for these calls is provided either by the
-file \fI/etc/hosts\fP, or by use of a nameserver.  If the data
-returned by \fIgethostbyname\fP are unsuitable, the lower level
-routine \fIgethostent\fP(3N) may be used.  For example, to
-obtain a \fIhostent\fP structure for a
-host on a particular network the following routine might be
-used (for simplicity, only Internet addresses are considered):
-.DS
-.if t .ta .5i 1.0i 1.5i 2.0i
-.\" 3.5i went to 3.8i
-.if n .ta .7i 1.4i 2.1i 2.8i 3.5i 4.2i
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <netdb.h>
- ...
-struct hostent *
-gethostbynameandnet(name, net)
-       char *name;
-       int net;
-{
-       register struct hostent *hp;
-       register char **cp;
-
-       sethostent(0);
-       while ((hp = gethostent()) != NULL) {
-               if (hp->h_addrtype != AF_INET)
-                       continue;
-               if (strcmp(name, hp->h_name)) {
-                       for (cp = hp->h_aliases; cp && *cp != NULL; cp++)
-                               if (strcmp(name, *cp) == 0)
-                                       goto found;
-                       continue;
-               }
-       found:
-               if (in_netof(*(struct in_addr *)hp->h_addr)) == net)
-                       break;
-       }
-       endhostent(0);
-       return (hp);
-}
-.DE
-(\fIin_netof\fP(3N) is a standard routine which returns
-the network portion of an Internet address.)
-\fIGethostent\fP can be used only
-by systems which use the \fI/etc/hosts\fP database; systems
-using nameservers cannot execute such a call.
+file \fI/etc/hosts\fP (\fIhosts\fP\|(5)),
+or by use of a nameserver, \fInamed\fP\|(8).
+Because of the differences in these databases and their access protocols,
+the information returned may differ.
+When using the host table version of \fIgethostbyname\fP,
+only one address will be returned, but all listed aliases will be included.
+The nameserver version may return alternate addresses,
+but will not provide any aliases other than one given as argument.
 .PP
 Unlike Internet names, NS names are always mapped into host
 addresses by the use of a standard NS \fIClearinghouse service\fP,
 .PP
 Unlike Internet names, NS names are always mapped into host
 addresses by the use of a standard NS \fIClearinghouse service\fP,
@@ -151,7 +141,7 @@ expected that almost all software that has to communicate
 using NS will need to use the facilities of
 the Courier compiler.
 .PP
 using NS will need to use the facilities of
 the Courier compiler.
 .PP
-A NS host address is represented by the following:
+An NS host address is represented by the following:
 .DS
 union ns_host {
        u_char  c_host[6];
 .DS
 union ns_host {
        u_char  c_host[6];
@@ -186,6 +176,8 @@ bzero((char *)&dst, sizeof(dst));
  * integer to a ``union ns_net'' at present; in
  * the future, something will hopefully be provided,
  * but this is the portable way to go for now.
  * integer to a ``union ns_net'' at present; in
  * the future, something will hopefully be provided,
  * but this is the portable way to go for now.
+ * The network number below is the one for the NS net
+ * that the desired host (gyre) is on.
  */
 netnum = htonl(2266);
 dst.sns_addr.x_net = *(union ns_net *) &netnum;
  */
 netnum = htonl(2266);
 dst.sns_addr.x_net = *(union ns_net *) &netnum;
@@ -264,8 +256,7 @@ a particular communication protocol.  This view is consistent with
 the Internet domain, but inconsistent with other network architectures.
 Further, a service may reside on multiple ports.
 If this occurs, the higher level library routines
 the Internet domain, but inconsistent with other network architectures.
 Further, a service may reside on multiple ports.
 If this occurs, the higher level library routines
-will have to be bypassed in favor of homegrown routines similar in
-spirit to the \*(lqgethostbynameandnet\*(rq routine described above.
+will have to be bypassed or extended.
 Services available are contained in the file \fI/etc/services\fP.
 A service mapping is described by the \fIservent\fP structure,
 .DS
 Services available are contained in the file \fI/etc/services\fP.
 A service mapping is described by the \fIservent\fP structure,
 .DS
@@ -351,8 +342,8 @@ Table 1.  C run-time routines.
 .KE
 .PP
 The byte swapping routines are provided because the operating
 .KE
 .PP
 The byte swapping routines are provided because the operating
-system expects addresses to be supplied in network order.  On
-some architectures, such as the VAX,
+system expects addresses to be supplied in network order (aka ``big-endian'' order).  On
+``little-endian'' architectures, such as Intel x86 and VAX,
 host byte ordering is different than
 network byte ordering.  Consequently,
 programs are sometimes required to byte swap quantities.  The
 host byte ordering is different than
 network byte ordering.  Consequently,
 programs are sometimes required to byte swap quantities.  The