library_15.html

Linux程序员的工作手册

<P>
<A NAME="IDX961"></A>
<DT><CODE>TRY_AGAIN</CODE>
<DD>This condition happens when the name server could not be contacted.  If
you try again later, you may succeed then.
<P>
<A NAME="IDX962"></A>
<DT><CODE>NO_RECOVERY</CODE>
<DD>A non-recoverable error occurred.
<P>
<A NAME="IDX963"></A>
<DT><CODE>NO_ADDRESS</CODE>
<DD>The host database contains an entry for the name, but it doesn't have an
associated Internet address.
</DL>
<P>
You can also scan the entire hosts database one entry at a time using
<CODE>sethostent</CODE>, <CODE>gethostent</CODE>, and <CODE>endhostent</CODE>.  Be careful
in using these functions, because they are not reentrant.
<P>
<A NAME="IDX964"></A>
<U>Function:</U> void <B>sethostent</B> <I>(int <VAR>stayopen</VAR>)</I><P>
This function opens the hosts database to begin scanning it.  You can
then call <CODE>gethostent</CODE> to read the entries.
<P>
If the <VAR>stayopen</VAR> argument is nonzero, this sets a flag so that
subsequent calls to <CODE>gethostbyname</CODE> or <CODE>gethostbyaddr</CODE> will
not close the database (as they usually would).  This makes for more
efficiency if you call those functions several times, by avoiding
reopening the database for each call.
<P>
<A NAME="IDX965"></A>
<U>Function:</U> struct hostent * <B>gethostent</B> <I>()</I><P>
This function returns the next entry in the hosts database.  It
returns a null pointer if there are no more entries.
<P>
<A NAME="IDX966"></A>
<U>Function:</U> void <B>endhostent</B> <I>()</I><P>
This function closes the hosts database.
<P>
<A NAME="IDX967"></A>
<H3><A NAME="SEC234" HREF="library_toc.html#SEC234" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC234">Internet Ports</A></H3>
<P>
A socket address in the Internet namespace consists of a machine's
Internet address plus a <DFN>port number</DFN> which distinguishes the
sockets on a given machine (for a given protocol).  Port numbers range
from 0 to 65,535.
<P>
Port numbers less than <CODE>IPPORT_RESERVED</CODE> are reserved for standard
servers, such as <CODE>finger</CODE> and <CODE>telnet</CODE>.  There is a database
that keeps track of these, and you can use the <CODE>getservbyname</CODE>
function to map a service name onto a port number; see section <A HREF="library_15.html#SEC235" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_15.html#SEC235">The Services Database</A>.
<P>
If you write a server that is not one of the standard ones defined in
the database, you must choose a port number for it.  Use a number
greater than <CODE>IPPORT_USERRESERVED</CODE>; such numbers are reserved for
servers and won't ever be generated automatically by the system.
Avoiding conflicts with servers being run by other users is up to you.
<P>
When you use a socket without specifying its address, the system
generates a port number for it.  This number is between
<CODE>IPPORT_RESERVED</CODE> and <CODE>IPPORT_USERRESERVED</CODE>.
<P>
On the Internet, it is actually legitimate to have two different
sockets with the same port number, as long as they never both try to
communicate with the same socket address (host address plus port
number).  You shouldn't duplicate a port number except in special
circumstances where a higher-level protocol requires it.  Normally,
the system won't let you do it; <CODE>bind</CODE> normally insists on
distinct port numbers.  To reuse a port number, you must set the
socket option <CODE>SO_REUSEADDR</CODE>.  See section <A HREF="library_15.html#SEC266" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_15.html#SEC266">Socket-Level Options</A>.
<A NAME="IDX968"></A>
<P>
These macros are defined in the header file <TT>`netinet/in.h'</TT>.
<P>
<A NAME="IDX969"></A>
<U>Macro:</U> int <B>IPPORT_RESERVED</B><P>
Port numbers less than <CODE>IPPORT_RESERVED</CODE> are reserved for
superuser use.
<P>
<A NAME="IDX970"></A>
<U>Macro:</U> int <B>IPPORT_USERRESERVED</B><P>
Port numbers greater than or equal to <CODE>IPPORT_USERRESERVED</CODE> are
reserved for explicit use; they will never be allocated automatically.
<P>
<A NAME="IDX971"></A>
<A NAME="IDX972"></A>
<A NAME="IDX973"></A>
<H3><A NAME="SEC235" HREF="library_toc.html#SEC235" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC235">The Services Database</A></H3>
<A NAME="IDX974"></A>
<P>
The database that keeps track of "well-known" services is usually
either the file <TT>`/etc/services'</TT> or an equivalent from a name server.
You can use these utilities, declared in <TT>`netdb.h'</TT>, to access
the services database.
<A NAME="IDX975"></A>
<P>
<A NAME="IDX976"></A>
<U>Data Type:</U> <B>struct servent</B><P>
This data type holds information about entries from the services database.
It has the following members:
<P>
<DL COMPACT>
<DT><CODE>char *s_name</CODE>
<DD>This is the "official" name of the service.
<P>
<DT><CODE>char **s_aliases</CODE>
<DD>These are alternate names for the service, represented as an array of
strings.  A null pointer terminates the array.
<P>
<DT><CODE>int s_port</CODE>
<DD>This is the port number for the service.  Port numbers are given in
network byte order; see section <A HREF="library_15.html#SEC236" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_15.html#SEC236">Byte Order Conversion</A>.
<P>
<DT><CODE>char *s_proto</CODE>
<DD>This is the name of the protocol to use with this service.
See section <A HREF="library_15.html#SEC237" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_15.html#SEC237">Protocols Database</A>.
</DL>
<P>
To get information about a particular service, use the
<CODE>getservbyname</CODE> or <CODE>getservbyport</CODE> functions.  The information
is returned in a statically-allocated structure; you must copy the
information if you need to save it across calls.
<P>
<A NAME="IDX977"></A>
<U>Function:</U> struct servent * <B>getservbyname</B> <I>(const char *<VAR>name</VAR>, const char *<VAR>proto</VAR>)</I><P>
The <CODE>getservbyname</CODE> function returns information about the
service named <VAR>name</VAR> using protocol <VAR>proto</VAR>.  If it can't find
such a service, it returns a null pointer.
<P>
This function is useful for servers as well as for clients; servers
use it to determine which port they should listen on (see section <A HREF="library_15.html#SEC246" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_15.html#SEC246">Listening for Connections</A>).
<P>
<A NAME="IDX978"></A>
<U>Function:</U> struct servent * <B>getservbyport</B> <I>(int <VAR>port</VAR>, const char *<VAR>proto</VAR>)</I><P>
The <CODE>getservbyport</CODE> function returns information about the
service at port <VAR>port</VAR> using protocol <VAR>proto</VAR>.  If it can't
find such a service, it returns a null pointer.
<P>
You can also scan the services database using <CODE>setservent</CODE>,
<CODE>getservent</CODE>, and <CODE>endservent</CODE>.  Be careful in using these
functions, because they are not reentrant.
<P>
<A NAME="IDX979"></A>
<U>Function:</U> void <B>setservent</B> <I>(int <VAR>stayopen</VAR>)</I><P>
This function opens the services database to begin scanning it.
<P>
If the <VAR>stayopen</VAR> argument is nonzero, this sets a flag so that
subsequent calls to <CODE>getservbyname</CODE> or <CODE>getservbyport</CODE> will
not close the database (as they usually would).  This makes for more
efficiency if you call those functions several times, by avoiding
reopening the database for each call.
<P>
<A NAME="IDX980"></A>
<U>Function:</U> struct servent * <B>getservent</B> <I>(void)</I><P>
This function returns the next entry in the services database.  If
there are no more entries, it returns a null pointer.
<P>
<A NAME="IDX981"></A>
<U>Function:</U> void <B>endservent</B> <I>(void)</I><P>
This function closes the services database.
<P>
<A NAME="IDX982"></A>
<A NAME="IDX983"></A>
<H3><A NAME="SEC236" HREF="library_toc.html#SEC236" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC236">Byte Order Conversion</A></H3>
<A NAME="IDX984"></A>
<A NAME="IDX985"></A>
<P>
Different kinds of computers use different conventions for the
ordering of bytes within a word.  Some computers put the most
significant byte within a word first (this is called "big-endian"
order), and others put it last ("little-endian" order).
<A NAME="IDX986"></A>
<P>
So that machines with different byte order conventions can
communicate, the Internet protocols specify a canonical byte order
convention for data transmitted over the network.  This is known
as the <DFN>network byte order</DFN>.
<P>
When establishing an Internet socket connection, you must make sure that
the data in the <CODE>sin_port</CODE> and <CODE>sin_addr</CODE> members of the
<CODE>sockaddr_in</CODE> structure are represented in the network byte order.
If you are encoding integer data in the messages sent through the
socket, you should convert this to network byte order too.  If you don't
do this, your program may fail when running on or talking to other kinds
of machines.
<P>
If you use <CODE>getservbyname</CODE> and <CODE>gethostbyname</CODE> or
<CODE>inet_addr</CODE> to get the port number and host address, the values are
already in the network byte order, and you can copy them directly into
the <CODE>sockaddr_in</CODE> structure.
<P>
Otherwise, you have to convert the values explicitly.  Use
<CODE>htons</CODE> and <CODE>ntohs</CODE> to convert values for the <CODE>sin_port</CODE>
member.  Use <CODE>htonl</CODE> and <CODE>ntohl</CODE> to convert values for the
<CODE>sin_addr</CODE> member.  (Remember, <CODE>struct in_addr</CODE> is equivalent
to <CODE>unsigned long int</CODE>.)  These functions are declared in
<TT>`netinet/in.h'</TT>.
<A NAME="IDX987"></A>
<P>
<A NAME="IDX988"></A>
<U>Function:</U> unsigned short int <B>htons</B> <I>(unsigned short int <VAR>hostshort</VAR>)</I><P>
This function converts the <CODE>short</CODE> integer <VAR>hostshort</VAR> from
host byte order to network byte order.
<P>
<A NAME="IDX989"></A>
<U>Function:</U> unsigned short int <B>ntohs</B> <I>(unsigned short int <VAR>netshort</VAR>)</I><P>
This function converts the <CODE>short</CODE> integer <VAR>netshort</VAR> from
network byte order to host byte order.
<P>
<A NAME="IDX990"></A>
<U>Function:</U> unsigned long int <B>htonl</B> <I>(unsigned long int <VAR>hostlong</VAR>)</I><P>
This function converts the <CODE>long</CODE> integer <VAR>hostlong</VAR> from
host byte order to network byte order.
<P>
<A NAME="IDX991"></A>
<U>Function:</U> unsigned long int <B>ntohl</B> <I>(unsigned long int <VAR>netlong</VAR>)</I><P>
This function converts the <CODE>long</CODE> integer <VAR>netlong</VAR> from
network byte order to host byte order.
<P>
<A NAME="IDX992"></A>
<H3><A NAME="SEC237" HREF="library_toc.html#SEC237" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC237">Protocols Database</A></H3>
<P>
The communications protocol used with a socket controls low-level
details of how data is exchanged.  For example, the protocol implements
things like checksums to detect errors in transmissions, and routing
instructions for messages.  Normal user programs have little reason to
mess with these details directly.
<A NAME="IDX993"></A>
<P>
The default communications protocol for the Internet namespace depends on
the communication style.  For stream communication, the default is TCP
("transmission control protocol").  For datagram communication, the
default is UDP ("user datagram protocol").  For reliable datagram
communication, the default is RDP ("reliable datagram protocol").
You should nearly always use the default.
<A NAME="IDX994"></A>
<P>
Internet protocols are generally specified by a name instead of a
number.  The network protocols that a host knows about are stored in a
database.  This is usually either derived from the file
<TT>`/etc/protocols'</TT>, or it may be an equivalent provided by a name
server.  You look up the protocol number associated with a named
protocol in the database using the <CODE>getprotobyname</CODE> function.
<P>
Here are detailed descriptions of the utilities for accessing the
protocols database.  These are declared in <TT>`netdb.h'</TT>.
<A NAME="IDX995"></A>
<P>
<A NAME="IDX996"></A>
<U>Data Type:</U> <B>struct protoent</B><P>
This data type is used to represent entries in the network protocols
database.  It has the following members:
<P>
<DL COMPACT>
<DT><CODE>char *p_name</CODE>
<DD>This is the official name of the protocol.
<P>
<DT><CODE>char **p_aliases</CODE>
<DD>These are alternate names for the protocol, specified as an array of
strings.  The last element of the array is a null pointer.
<P>
<DT><CODE>int p_proto</CODE>
<DD>This is the protocol number (in host byte order); use this member as the
<VAR>protocol</VAR> argument to <CODE>socket</CODE>.
</DL>
<P>
You can use <CODE>getprotobyname</CODE> and <CODE>getprotobynumber</CODE> to search
the protocols database for a specific protocol.  The information is
returned in a statically-allocated structure; you must copy the