INTRO(4N)                                                            INTRO(4N)


NAME
       networking - introduction to networking facilities

SYNOPSIS
       #include <sys/socket.h>
       #include <net/route.h>
       #include <net/if.h>

DESCRIPTION
       This  section  briefly describes the networking facilities available in
       the system.  Documentation in this part of section 4 is broken up  into
       three areas: protocol families (domains), protocols, and network inter
       faces.  Entries describing a protocol family are marked  ‘‘4F,’’  while
       entries  describing  protocol  use are marked ‘‘4P.’’  Hardware support
       for network interfaces are found among the standard ‘‘4’’ entries.

       All network protocols are associated with a specific  protocol  family.
       A  protocol  family provides basic services to the protocol implementa‐
       tion to allow it to function within  a  specific  network  environment.
       These  services  may include packet fragmentation and reassembly, rout‐
       ing, addressing, and basic transport.  A protocol  family  may  support
       multiple methods of addressing, though the current protocol implementa‐
       tions do not.  A protocol family is normally comprised of a  number  of
       protocols,  one per socket(2) type.  It is not required that a protocol
       family support all socket types.  A protocol family may contain  multi‐
       ple protocols supporting the same socket abstraction.

       A  protocol  supports  one  of  the  socket  abstractions  detailed  in
       socket(2).  A specific protocol may be accessed either  by  creating  a
       socket  of  the  appropriate type and protocol family, or by requesting
       the protocol explicitly when creating  a  socket.   Protocols  normally
       accept  only  one  type  of  address  format, usually determined by the
       addressing structure inherent in the design of the protocol family/net‐
       work  architecture.  Certain semantics of the basic socket abstractions
       are protocol specific.  All protocols are expected to support the basic
       model  for  their particular socket type, but may, in addition, provide
       non-standard facilities or extensions to a mechanism.  For  example,  a
       protocol supporting the SOCK_STREAM abstraction may allow more than one
       byte of out-of-band data to be transmitted per out-of-band message.

       A network interface is similar to a device interface.   Network  inter‐
       faces  comprise the lowest layer of the networking subsystem, interact‐
       ing with the actual transport hardware.  An interface may  support  one
       or more protocol families and/or address formats.  The SYNOPSIS section
       of each network interface entry gives a  sample  specification  of  the
       related  drivers  for use in providing a system description to the con
       fig(8) program.  The  DIAGNOSTICS  section  lists  messages  which  may
       appear on the console and/or in the system error log, /usr/adm/messages
       (see syslogd(8)), due to errors in device operation.

PROTOCOLS
       The system currently supports the  DARPA  Internet  protocols  and  the
       Xerox  Network  Systems(tm)  protocols.  Raw socket interfaces are pro‐
       vided to the IP protocol layer of the DARPA Internet, to the  IMP  link
       layer  (1822), and to the IDP protocol of Xerox NS.  Consult the appro‐
       priate manual pages in this section for more information regarding  the
       support for each protocol family.

ADDRESSING
       Associated with each protocol family is an address format.  The follow‐
       ing address formats are used by the system (and additional formats  are
       defined for possible future implementation):

       #define AF_UNIX           1      /* local to host (pipes, portals) */
       #define AF_INET           2      /* internetwork: UDP, TCP, etc. */
       #define AF_IMPLINK        3      /* arpanet imp addresses */
       #define AF_PUP            4      /* pup protocols: e.g. BSP */
       #define AF_NS             6      /* Xerox NS protocols */
       #define AF_HYLINK         15     /* NSC Hyperchannel */

ROUTING
       The  network  facilities provided limited packet routing.  A simple set
       of data structures comprise a ‘‘routing table’’ used in  selecting  the
       appropriate  network  interface  when transmitting packets.  This table
       contains a single entry for each route to a specific network  or  host.
       A  user  process, the routing daemon, maintains this data base with the
       aid of two socket-specific ioctl(2) commands, SIOCADDRT and  SIOCDELRT.
       The  commands allow the addition and deletion of a single routing table
       entry, respectively.  Routing table manipulations may only  be  carried
       out by super-user.

       A   routing   table  entry  has  the  following  form,  as  defined  in
       <net/route.h>;

       struct rtentry {
              u_long    rt_hash;
              struct    sockaddr rt_dst;
              struct    sockaddr rt_gateway;
              short     rt_flags;
              short     rt_refcnt;
              u_long    rt_use;
              struct    ifnet *rt_ifp;
       };

       with rt_flags defined from,

       #define RTF_UP            0x1    /* route usable */
       #define RTF_GATEWAY       0x2    /* destination is a gateway */
       #define RTF_HOST          0x4    /* host entry (net otherwise) */
       #define RTF_DYNAMIC       0x10   /* created dynamically (by redirect) */

       Routing table entries come in three flavors: for a specific  host,  for
       all  hosts  on  a  specific network, for any destination not matched by
       entries of the first two types (a wildcard route).  When the system  is
       booted  and addresses are assigned to the network interfaces, each pro‐
       tocol family installs a routing table entry for each interface when  it
       is  ready  for  traffic.   Normally  the  protocol  specifies the route
       through each interface as a ‘‘direct’’ connection  to  the  destination
       host or network.  If the route is direct, the transport layer of a pro‐
       tocol family usually requests the packet be sent to the same host spec‐
       ified  in the packet.  Otherwise, the interface is requested to address
       the packet to the gateway listed in the routing entry (i.e. the  packet
       is forwarded).

       Routing  table  entries installed by a user process may not specify the
       hash, reference count, use, or interface fields; these are filled in by
       the  routing  routines.   If  a  route  is  in  use  when it is deleted
       (rt_refcnt is non-zero), the routing entry  will  be  marked  down  and
       removed  from  the  routing table, but the resources associated with it
       will not be reclaimed until all references to  it  are  released.   The
       routing  code  returns  EEXIST  if  requested  to duplicate an existing
       entry, ESRCH if requested to delete a non-existent entry, or ENOBUFS if
       insufficient  resources  were  available  to install a new route.  User
       processes read the routing tables through the  /dev/kmem  device.   The
       rt_use field contains the number of packets sent along the route.

       When routing a packet, the kernel will first attempt to find a route to
       the destination host.  Failing that, a search is made for  a  route  to
       the  network  of  the  destination.   Finally,  any  route to a default
       (‘‘wildcard’’) gateway is chosen.  If multiple routes  are  present  in
       the  table,  the first route found will be used.  If no entry is found,
       the destination is declared to be unreachable.

       A wildcard routing entry is specified with a zero  destination  address
       value.   Wildcard  routes are used only when the system fails to find a
       route to the destination host and network.  The combination of wildcard
       routes  and  routing  redirects can provide an economical mechanism for
       routing traffic.

INTERFACES
       Each network interface in a system corresponds to a path through  which
       messages  may  be sent and received.  A network interface usually has a
       hardware device associated with it, though certain interfaces  such  as
       the loopback interface, lo(4), do not.

       The following ioctl calls may be used to manipulate network interfaces.
       The ioctl is made on a socket (typically of  type  SOCK_DGRAM)  in  the
       desired domain.  Unless specified otherwise, the request takes an ifre
       quest structure as its parameter.  This structure has the form

       struct    ifreq {
            char ifr_name[16];       /* name of interface (e.g. "ec0") */
            union {
                 struct    sockaddr ifru_addr;
                 struct    sockaddr ifru_dstaddr;
                 struct    sockaddr ifru_broadaddr;
                 short     ifru_flags;
                 int  ifru_metric;
            } ifr_ifru;
       #define   ifr_addr  ifr_ifru.ifru_addr  /* address */
       #define   ifr_dstaddr    ifr_ifru.ifru_dstaddr    /* other end of p-to-p link */
       #define   ifr_broadaddr  ifr_ifru.ifru_broadaddr  /* broadcast address */
       #define   ifr_flags ifr_ifru.ifru_flags /* flags */
       #define   ifr_metric     ifr_ifru.ifru_metric     /* routing metric */
       };

       SIOCSIFADDR
              Set  interface  address  for  protocol  family.   Following  the
              address  assignment,  the  ‘‘initialization’’  routine  for  the
              interface is called.

       SIOCGIFADDR
              Get interface address for protocol family.

       SIOCSIFDSTADDR
              Set point to point address for protocol family and interface.

       SIOCGIFDSTADDR
              Get point to point address for protocol family and interface.

       SIOCSIFBRDADDR
              Set broadcast address for protocol family and interface.

       SIOCGIFBRDADDR
              Get broadcast address for protocol family and interface.

       SIOCSIFFLAGS
              Set interface flags field.  If the interface is marked down, any
              processes  currently  routing  packets through the interface are
              notified; some interfaces may be reset so that incoming  packets
              are  no longer received.  When marked up again, the interface is
              reinitialized.

       SIOCGIFFLAGS
              Get interface flags.

       SIOCSIFMETRIC
              Set interface routing metric.  The metric is used only by  user-
              level routers.

       SIOCGIFMETRIC
              Get interface metric.

       SIOCGIFCONF
              Get  interface configuration list.  This request takes an ifconf
              structure (see below) as a value-result parameter.  The  ifc_len
              field  should be initially set to the size of the buffer pointed
              to by ifc_buf.  On return it will contain the length, in  bytes,
              of the configuration list.

       /*
        * Structure used in SIOCGIFCONF request.
        * Used to retrieve interface configuration
        * for machine (useful for programs which
        * must know all networks accessible).
        */
       struct    ifconf {
            int  ifc_len;       /* size of associated buffer */
            union {
                 caddr_t   ifcu_buf;
                 struct    ifreq *ifcu_req;
            } ifc_ifcu;
       #define   ifc_buf   ifc_ifcu.ifcu_buf   /* buffer address */
       #define   ifc_req   ifc_ifcu.ifcu_req   /* array of structures returned */
       };

SEE ALSO
       socket(2), ioctl(2), intro(4), config(8), routed(8C)


4.2 Berkeley Distribution        June 1, 1986                        INTRO(4N)
 
Generated: 2016-12-26
Generated by man2html V0.25
page hit count: 397
Valid CSS Valid XHTML 1.0 Strict