inet(5F)                                                 inet(5F)



     NAME
          inet - Internet protocol family

     SYNOPSIS
          #include <sys/types.h>
          #include <netinet/in.h>

     DESCRIPTION
          The Internet protocol family is a collection of protocols
          layered atop the Internet Protocol (IP) transport layer, and
          utilizing the Internet address format.  The Internet family
          provides protocol support for the SOCK_STREAM, SOCK_DGRAM,
          and SOCK_RAW socket types; the SOCK_RAW interface provides
          access to the IP protocol.

     ADDRESSING
          Internet addresses are four byte quantities, stored in net-
          work standard format (on the VAX these are word and byte re-
          versed).  The include file <netinet/in.h> defines this ad-
          dress as a discriminated union.

          Sockets bound to the Internet protocol family utilize the
          following addressing structure,

             struct sockaddr_in {
                     short   sin_family;
                     u_short sin_port;
                     struct  in_addr sin_addr;
                     char    sin_zero[8];
             };

          Sockets may be created with the address INADDR_ANY to effect
          ``wildcard'' matching on incoming messages.

     PROTOCOLS
          The Internet protocol family is comprised of the IP tran-
          sport protocol, Internet Control Message Protocol (ICMP),
          Transmission Control Protocol (TCP), and User Datagram Pro-
          tocol (UDP).  TCP is used to support the SOCK_STREAM
          abstraction while UDP is used to support the SOCK_DGRAM
          abstraction.  A raw interface to IP is available by creating
          an Internet socket of type SOCK_RAW.  The ICMP message pro-
          tocol is not directly accessible.

     SEE ALSO
          tcp(5P), udp(5P), ip(5P).

     CAVEAT
          The Internet protocol support is subject to change as the
          Internet protocols develop.  Users should not depend on de-
          tails of the current implementation, but rather the services
          exported.



     April, 1990                                                     1