netintro man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

netintro(7)							   netintro(7)

NAME
       netintro, networking - Introduction to socket networking facilities

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

DESCRIPTION
       This  section  is  a  general introduction to the networking facilities
       available in the system. Documentation in this part  of	Section	 7  is
       broken up into three areas: protocol families (domains), protocols, and
       network interfaces.

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

       A protocol supports one of the socket abstractions detailed in the ref‐
       erence page for the socket()  function.	A  specific  protocol  may  be
       accessed either by creating a socket of the appropriate type and proto‐
       col family, or by requesting the protocol explicitly  when  creating  a
       socket. Protocols normally accept only one type of address format, usu‐
       ally determined by the addressing structure inherent in the  design  of
       the  protocol family and network 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 nonstandard facilities or extensions to a
       mechanism.  For example, a protocol supporting the SOCK_STREAM abstrac‐
       tion 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, address formats, or both. The SYNOPSIS  sec‐
       tion  of	 each  network interface entry gives a sample specification of
       the related drivers for use in providing a system  description  to  the
       config  program.	 The ERRORS section lists messages which may appear on
       the console and/or in the system error log, /var/log/messages (see  the
       syslogd function), due to errors in device operation.

       The  system currently supports the DARPA Internet protocols. Raw socket
       interfaces are provided to the IP layer of the DARPA Internet.  Consult
       the  appropriate	 manual	 pages	in  this  section for more information
       regarding this support.

   Addressing
       Associated with each protocol family is an address format.  All network
       address	adhere	to  a  general structure, called a sockaddr.  However,
       each protocol imposes finer  and	 more  specific	 structure,  generally
       renaming the variant.

       Both  the  4.3BSD and 4.4BSD sockaddr structures are supported by Tru64
       UNIX. The default sockaddr structure is the 4.3BSD structure, which  is
       as follows: struct sockaddr(
	       u_short sa_family,
	       char sa_data[14] );

       If   the	 compile-time  option  _SOCKADDR_LEN  is  defined  before  the
       sys/socket.h header file is  included,  however,	 the  4.4BSD  sockaddr
       structure is defined, which is as follows: struct sockaddr(
	       u_char sa_len,
	       u_char sa_family,
	       char   sa_data[14] );

       The  4.4BSD  sockaddr structure provides for a sa_len field, which con‐
       tains the total length of the structure.	 Unlike	 the  4.3BSD  sockaddr
       structure, this length may exceed 16 bytes.

       The following address values for sa_family are known to 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 (IPv4 address format)
       */ #define AF_INET6 26 /* internetwork: UDP, TCP (IPv6 address  format)
       */

       Internet	 domain addresses vary with the underlying protocol.  The fol‐
       lowing  table  lists  the  underlying  protocol	and  their  associated
       addresses:

       ────────────────────────
       Protocol	  Address
       ────────────────────────
       IPv4	  sockaddr_in
       IPv6	  sockaddr_in6
       ────────────────────────

   IPv4 Addressing
       The sockaddr_in structure, defined in <netinet/in.h>, is the IPv4 sock‐
       addr variant, and is as follows: struct sockaddr_in(
	       u_short sin_family,
	       u_short sin_port,
	       struct in_addr sin_addr,
	       char sin_zero[8] );

       If  the	compile-time  option  _SOCKADDR_LEN  is	 defined  before   the
       sys/socket.h  header  file is included, however, the 4.4BSD sockaddr_in
       structure is defined, which is as follows: struct sockaddr_in(
	       u_char sin_len,
	       sa_family_t sin_family,
	       in_port_t sin_port,
	       struct in_addr sin_addr,
	       char sin_zero[8] );

   IPv6 Addressing
       The sockaddr_in6 structure, defined in  <netinet/in6.h>,	 is  the  IPv6
       sockaddr variant, and is as follows: struct sockaddr_in6(
	       unsigned short sin6_family,
	       in_port_t sin_port,
	       uint32_t sin6_flowinfo,
	       struct in6_addr sin6_addr,
	       uint32_t sin6_scope_id );

       If   the	 compile-time  option  _SOCKADDR_LEN  is  defined  before  the
       sys/socket.h header file is included, however, the 4.4BSD  sockaddr_in6
       structure is defined, which is as follows: struct sockaddr_in6(
	       uint8_t sin6_len,
	       sa_family_t sin6_family,
	       in_port_t sin_port,
	       uint32_t sin6_flowinfo,
	       struct in6_addr sin6_addr,
	       uint32_t sin6_scope_id );

       The in6_addr structure is defined in <netinet/in6.h>.

   Routing
       The  UNIX operating system provides packet routing facilities. The ker‐
       nel maintains a routing information database, which is used in  select‐
       ing the appropriate network interface when transmitting packets.

       A  user	process (or possibly multiple cooperating processes) maintains
       this database by sending messages over a special kind of	 socket.  This
       supplants fixed size ioctl's used in earlier releases.

       This  facility is described in the files reference page for the route()
       function.

   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, 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. Most of the requests supported in earlier releases take
       an ifreq structure as its parameter.  This structure has the  following
       form:

       struct ifreq { #define IFNAMSIZ 16
	 char ifr_name[IFNAMSIZE]; /*interface name */
	 union {
	    struct sockaddr ifru_addr;
	    struct sockaddr ifru_dstaddr;
	    struct sockaddr ifru_broadaddr;
	    short	    ifru_flags;
	    int		    ifru_metric;
	    caddr_t	    ifru_data;
	    } ifr_ifru; #define		 ifr_addr      ifr_ifru.ifru_addr
		       /*     address	 */    #define		   ifr_dstaddr
       ifr_ifru.ifru_dstaddr
			       /*   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			      /*   metric  */  #define
       ifr_data	     ifr_ifru.ifru_data
			       /* for use by interface */ };

       Calls which are now deprecated are: Sets interface address for protocol
       family.	 Following the address assignment, the ``initialization'' rou‐
       tine for the interface is called.  Sets point to point address for pro‐
       tocol family and interface.  Sets broadcast address for protocol family
       and interface. All ioctl requests to obtain addresses and requests both
       to  set	and  retrieve other data are still fully supported and use the
       ifreq structure: Gets interface	address	 for  protocol	family.	  Gets
       point-to-point  address for protocol family and interface.  Gets broad‐
       cast address for protocol family and interface.	Gets the network  mask
       for protocol family and interface.  Sets 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.   Gets  interface	flags.	Sets interface
       routing metric.	The metric is used only by user-level  routers.	  Gets
       interface metric.

       There are three requests that make use of a new structure: An interface
       may have more than one address associated with it  in  some  protocols.
       This  request  provides	a means to add additional addresses (or modify
       characteristics of the primary address if the default address  for  the
       address family is specified).  Rather than making separate calls to set
       destination addresses, broadcast addresses, or network  masks  (now  an
       integral feature of multiple protocols) a separate structure is used to
       specify all three facets simultaneously: struct ifaliasreq(
	       char ifra_name[IFNAMSIZ],
	       struct sockaddr ifra_addr,
	       struct sockaddr ifra_broadaddr,
	       struct sockaddr ifra_mask );

	      You would use a slightly tailored version of this structure  for
	      each  family  (replacing each sockaddr by one of the family-spe‐
	      cific type). When the sockaddr itself is larger than the default
	      size, you must modify the ioctl identifier itself to include the
	      total size.  This request deletes the specified address from the
	      list  associated	with  an  interface.   It uses the if_aliasreq
	      structure to permit protocols to allow multiple masks or	desti‐
	      nation  addresses,  and it adopts the convention that specifica‐
	      tion of the default address means to delete  the	first  address
	      for  the	interface belonging to the address family in which the
	      original socket was opened.  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 con‐
	      tains 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   */  #define
	      ifc_req	 ifc_ifcu.ifcu_req
			 /* array of structures returned */ };

SEE ALSO
       Functions: socket(2), ioctl(2)

       Files: config(8), routed(8)

       Network Programmer's Guide

								   netintro(7)
[top]

List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net