networking man page on NeXTSTEP

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


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
       interfaces.  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
       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 multiple methods of addressing, though  the  current
       protocol	 implementations  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  multiple  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/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 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
       interfaces comprise the	lowest	layer  of  the	networking  subsystem,
       interacting  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  config(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
       provided 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
       appropriate 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
       following 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
       protocol 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
       protocol family usually requests the packet be sent to  the  same  host
       specified  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
       ifrequest 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)
[top]

List of man pages available for NeXTSTEP

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