home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / a_man / cat7 / netintro.z / netintro
Encoding:
Text File  |  2002-10-03  |  13.9 KB  |  331 lines
  1.  
  2.  
  3.  
  4. NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))                                                        NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      networking - introduction to networking facilities
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      ####iiiinnnncccclllluuuuddddeeee <<<<ssssyyyyssss////ssssoooocccckkkkeeeetttt....hhhh>>>>
  13.      ####iiiinnnncccclllluuuuddddeeee <<<<nnnneeeetttt////rrrroooouuuutttteeee....hhhh>>>>
  14.      ####iiiinnnncccclllluuuuddddeeee <<<<nnnneeeetttt////iiiiffff....hhhh>>>>
  15.  
  16. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  17.      This section briefly describes the networking facilities available in the
  18.      system.  Documentation in this part of section 7 is broken up into three
  19.      areas:  _p_r_o_t_o_c_o_l _f_a_m_i_l_i_e_s (domains), _p_r_o_t_o_c_o_l_s, and _n_e_t_w_o_r_k _i_n_t_e_r_f_a_c_e_s.
  20.      Entries describing a protocol family are marked ``7F,'' while entries
  21.      describing protocol use are marked ``7P.''  Hardware support for network
  22.      interfaces are found among the standard ``7'' entries.
  23.  
  24.      All network protocols are associated with a specific _p_r_o_t_o_c_o_l _f_a_m_i_l_y.  A
  25.      protocol family provides basic services to the protocol implementation to
  26.      allow it to function within a specific network environment.  These
  27.      services may include packet fragmentation and reassembly, routing,
  28.      addressing, and basic transport.  A protocol family may support multiple
  29.      methods of addressing, though the current protocol implementations do
  30.      not.  A protocol family is normally comprised of a number of protocols,
  31.      one per _s_o_c_k_e_t(2) type.  It is not required that a protocol family
  32.      support all socket types.  A protocol family may contain multiple
  33.      protocols supporting the same socket abstraction.
  34.  
  35.      A protocol supports one of the socket abstractions detailed in _s_o_c_k_e_t(2).
  36.      A specific protocol may be accessed either by creating a socket of the
  37.      appropriate type and protocol family, or by requesting the protocol
  38.      explicitly when creating a socket.  Protocols normally accept only one
  39.      type of address format, usually determined by the addressing structure
  40.      inherent in the design of the protocol family/network architecture.
  41.      Certain semantics of the basic socket abstractions are protocol specific.
  42.      All protocols are expected to support the basic model for their
  43.      particular socket type, but may, in addition, provide non-standard
  44.      facilities or extensions to a mechanism.  For example, a protocol
  45.      supporting the SOCK_STREAM abstraction may allow more than one byte of
  46.      out-of-band data to be transmitted per out-of-band message.
  47.  
  48.      A network interface is similar to a device interface.  Network interfaces
  49.      comprise the lowest layer of the networking subsystem, interacting with
  50.      the actual transport hardware.  An interface may support one or more
  51.      protocol families and/or address formats.  The _e_t_h_e_r_n_e_t(7) manual entry
  52.      lists messages which may appear on the console and/or in the system error
  53.      log, /_v_a_r/_a_d_m/_S_Y_S_L_O_G (see _s_y_s_l_o_g_d(1M)), due to errors in device
  54.      operation.
  55.  
  56. PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLLSSSS
  57.      The system currently supports the DARPA Internet protocols.  Raw socket
  58.      interfaces are provided to the IP protocol layer of the DARPA Internet
  59.      and to the link-level layer.  Consult the appropriate manual pages in
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))                                                        NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))
  71.  
  72.  
  73.  
  74.      this section for more information regarding the support for each protocol
  75.      family.
  76.  
  77. AAAADDDDDDDDRRRREEEESSSSSSSSIIIINNNNGGGG
  78.      Associated with each protocol family is an address format.  The following
  79.      address formats are used by the system (and additional formats are
  80.      defined for possible future implementation):
  81.  
  82.      #define AF_UNIX           1      /* _l_o_c_a_l _t_o _h_o_s_t (_p_i_p_e_s) */
  83.      #define AF_INET           2      /* _i_n_t_e_r_n_e_t_w_o_r_k: _U_D_P, _T_C_P, _e_t_c. */
  84.  
  85. RRRROOOOUUUUTTTTIIIINNNNGGGG
  86.      The network facilities provided limited packet routing.  A simple set of
  87.      data structures comprise a ``routing table'' used in selecting the
  88.      appropriate network interface when transmitting packets.  This table
  89.      contains a single entry for each route to a specific network or host.  A
  90.      user process, the routing daemon, maintains this data base with the aid
  91.      of two socket-specific _i_o_c_t_l(2) commands, SIOCADDRT and SIOCDELRT.  The
  92.      commands allow the addition and deletion of a single routing table entry,
  93.      respectively.  Routing table manipulations may only be carried out by
  94.      super-user.
  95.  
  96.      A routing table entry has the following form, as defined in
  97.      <_n_e_t/_r_o_u_t_e._h>;
  98.  
  99.      struct rtentry {
  100.             u_long    rt_hash;
  101.             struct    sockaddr rt_dst;
  102.             struct    sockaddr rt_gateway;
  103.             short     rt_flags;
  104.             short     rt_refcnt;
  105.             u_long    rt_use;
  106.             struct    ifnet *rt_ifp;
  107.      };
  108.  
  109.      with _r_t__f_l_a_g_s defined from,
  110.  
  111.      #define RTF_UP            0x1    /* _r_o_u_t_e _u_s_a_b_l_e */
  112.      #define RTF_GATEWAY       0x2    /* _d_e_s_t_i_n_a_t_i_o_n _i_s _a _g_a_t_e_w_a_y */
  113.      #define RTF_HOST          0x4    /* _h_o_s_t _e_n_t_r_y (_n_e_t _o_t_h_e_r_w_i_s_e) */
  114.      #define RTF_DYNAMIC       0x10   /* _c_r_e_a_t_e_d _d_y_n_a_m_i_c_a_l_l_y (_b_y _r_e_d_i_r_e_c_t) */
  115.      #define RTF_MODIFIED      0x10   /* _m_o_d_i_f_i_e_d _d_y_n_a_m_i_c_a_l_l_y (_b_y _r_e_d_i_r_e_c_t) */
  116.  
  117.      Routing table entries come in three flavors: for a specific host, for all
  118.      hosts on a specific network, for any destination not matched by entries
  119.      of the first two types (a wildcard route). When the system is booted and
  120.      addresses are assigned to the network interfaces, each protocol family
  121.      installs a routing table entry for each interface when it is ready for
  122.      traffic.  Normally the protocol specifies the route through each
  123.      interface as a ``direct'' connection to the destination host or network.
  124.      If the route is direct, the transport layer of a protocol family usually
  125.      requests the packet be sent to the same host specified in the packet.
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))                                                        NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))
  137.  
  138.  
  139.  
  140.      Otherwise, the interface is requested to address the packet to the
  141.      gateway listed in the routing entry (i.e., the packet is forwarded).
  142.  
  143.      Routing table entries installed by a user process may not specify the
  144.      hash, reference count, use, or interface fields; these are filled in by
  145.      the routing routines.  If a route is in use when it is deleted (_r_t__r_e_f_c_n_t
  146.      is non-zero), the routing entry will be marked down and removed from the
  147.      routing table, but the resources associated with it will not be reclaimed
  148.      until all references to it are released. The routing code returns EEXIST
  149.      if requested to duplicate an existing entry, ESRCH if requested to delete
  150.      a non-existent entry, or ENOBUFS if insufficient resources were available
  151.      to install a new route.  User processes read the routing tables through
  152.      the /_d_e_v/_k_m_e_m device.  The _r_t__u_s_e field contains the number of packets
  153.      sent along the route.
  154.  
  155.      When routing a packet, the kernel will first attempt to find a route to
  156.      the destination host.  Failing that, a search is made for a route to the
  157.      network of the destination.  Finally, any route to a default
  158.      (``wildcard'') gateway is chosen.  If multiple routes are present in the
  159.      table, the first route found will be used.  If no entry is found, the
  160.      destination is declared to be unreachable.
  161.  
  162.      A wildcard routing entry is specified with a zero destination address
  163.      value.  Wildcard routes are used only when the system fails to find a
  164.      route to the destination host and network.  The combination of wildcard
  165.      routes and routing redirects can provide an economical mechanism for
  166.      routing traffic.
  167.  
  168. IIIINNNNTTTTEEEERRRRFFFFAAAACCCCEEEESSSS
  169.      Each network interface in a system corresponds to a path through which
  170.      messages may be sent and received.  A network interface usually has a
  171.      hardware device associated with it, though certain interfaces such as the
  172.      loopback interface, _l_o(7), do not.
  173.  
  174.      The following _i_o_c_t_l calls may be used to manipulate network interfaces.
  175.      The _i_o_c_t_l is made on a socket (typically of type SOCK_DGRAM) in the
  176.      desired domain.  Unless specified otherwise, the request takes an
  177.      _i_f_r_e_q_u_e_s_t structure as its parameter.  This structure has the form
  178.  
  179.      struct    ifreq {
  180.      #define   IFNAMSIZ  16
  181.           char ifr_name[IFNAMSIZE];          /* _i_f _n_a_m_e, _e._g. "_e_n_p_0" */
  182.           union {
  183.                struct    sockaddr ifru_addr;
  184.                struct    sockaddr ifru_dstaddr;
  185.                struct    sockaddr ifru_broadaddr;
  186.                short     ifru_flags;
  187.                int  ifru_metric;
  188.                caddr_t   ifru_data;
  189.           } ifr_ifru;
  190.      #define   ifr_addr       ifr_ifru.ifru_addr       /* _a_d_d_r_e_s_s */
  191.      #define   ifr_dstaddr    ifr_ifru.ifru_dstaddr    /* _o_t_h_e_r _e_n_d _o_f _p-_t_o-_p _l_i_n_k */
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))                                                        NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))
  203.  
  204.  
  205.  
  206.      #define   ifr_broadaddr  ifr_ifru.ifru_broadaddr  /* _b_r_o_a_d_c_a_s_t _a_d_d_r_e_s_s */
  207.      #define   ifr_flags      ifr_ifru.ifru_flags      /* _f_l_a_g_s */
  208.      #define   ifr_metric     ifr_ifru.ifru_metric          /* _m_e_t_r_i_c */
  209.      #define   ifr_data       ifr_ifru.ifru_data       /* _f_o_r _u_s_e _b_y _i_n_t_e_r_f_a_c_e */
  210.      };
  211.  
  212.      SIOCSIFADDR
  213.           Set interface address for protocol family.  Following the address
  214.           assignment, the ``initialization'' routine for the interface is
  215.           called.
  216.  
  217.      SIOCGIFADDR
  218.           Get interface address for protocol family.
  219.  
  220.      SIOCSIFDSTADDR
  221.           Set point to point address for protocol family and interface.
  222.  
  223.      SIOCGIFDSTADDR
  224.           Get point to point address for protocol family and interface.
  225.  
  226.      SIOCSIFBRDADDR
  227.           Set broadcast address for protocol family and interface.
  228.  
  229.      SIOCGIFBRDADDR
  230.           Get broadcast address for protocol family and interface.
  231.  
  232.      SIOCSIFFLAGS
  233.           Set interface flags field.  If the interface is marked down, any
  234.           processes currently routing packets through the interface are
  235.           notified; some interfaces may be reset so that incoming packets are
  236.           no longer received.  When marked up again, the interface is
  237.           reinitialized.
  238.  
  239.      SIOCGIFFLAGS
  240.           Get interface flags.
  241.  
  242.      SIOCSIFMETRIC
  243.           Set interface routing metric.  The metric is used only by user-level
  244.           routers.
  245.  
  246.      SIOCGIFMETRIC
  247.           Get interface metric.
  248.  
  249.      SIOCGIFCONF
  250.           Get interface configuration list.  This request takes an _i_f_c_o_n_f
  251.           structure (see below) as a value-result parameter.  The _i_f_c__l_e_n
  252.           field should be initially set to the size of the buffer pointed to
  253.           by _i_f_c__b_u_f.  On return it will contain the length, in bytes, of the
  254.           configuration list.
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))                                                        NNNNEEEETTTTIIIINNNNTTTTRRRROOOO((((7777))))
  269.  
  270.  
  271.  
  272.      /*
  273.       * Structure used in SIOCGIFCONF request.
  274.       * Used to retrieve interface configuration
  275.       * for machine (useful for programs which
  276.       * must know all networks accessible).
  277.       */
  278.      struct    ifconf {
  279.           int  ifc_len;       /* _s_i_z_e _o_f _a_s_s_o_c_i_a_t_e_d _b_u_f_f_e_r */
  280.           union {
  281.                caddr_t   ifcu_buf;
  282.                struct    ifreq *ifcu_req;
  283.           } ifc_ifcu;
  284.      #define   ifc_buf   ifc_ifcu.ifcu_buf   /* _b_u_f_f_e_r _a_d_d_r_e_s_s */
  285.      #define   ifc_req   ifc_ifcu.ifcu_req   /* _a_r_r_a_y _o_f _s_t_r_u_c_t_u_r_e_s _r_e_t_u_r_n_e_d */
  286.      };
  287.  
  288. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  289.      socket(2), ioctl(2), routed(1M), route(7F), _I_R_I_X _N_e_t_w_o_r_k _P_r_o_g_r_a_m_m_i_n_g
  290.      _G_u_i_d_e.
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.                                                                         PPPPaaaaggggeeee 5555
  328.  
  329.  
  330.  
  331.