Museum

Home

Lab Overview

Retrotechnology Articles

⇒ Online Manual

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

intro(3N)

byteorder(3N)

gethostent(3N)

getnetent(3N)

getprotoent(3N)

getservent(3N)

inet(3N)

arp(4P)

tcp(4P)

udp(4P)

ip(4P)

INET(4F)  —  SPECIAL FILES

NAME

inet − Internet protocol family

SYNOPSIS

options INET

DESCRIPTION

The Internet protocol family is a collection of protocols layered atop the Internet Protocol (IP) transport layer, and using 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 network standard format (on the VAX these are word and byte reversed; on the Sun they are not reversed).  The include file <netinet/in.h> defines the Internet address as a discriminated union.

Sockets in the Internet protocol family use the following addressing structure:

struct sockaddr_in {
shortsin_family;
u_shortsin_port;
structin_addr sin_addr;
charsin_zero[8];
};

(Library routines to return and manipulate structures of this form are in section 3N of the manual; see intro(3N) and the other section 3 entries mentioned under SEE ALSO below). Each socket has a local address which may be specified in this form, which can be established with bind(2); the getsockname(2) call returns this address. Each socket also may be bound to a peer socket with an address specified in this form; this peer address can be specified in a connect(2) call, or transiently with a single message in a sendto or sendmsg call; see send(2). The peer address of a socket is returned by the getpeername(2) call.

The sin_addr field of the socket address specifies the Internet address of the machine on which the socket is located.  A special value may be specified or returned for this field, sin_addr.s_addr==INADDR_ANY.  This address is a “wildcard” and matches any of the legal internet addresses on the local machine.  This address is useful when a process neither knows (nor cares) what the local Internet address is, and even more useful for server processes which wish to  service all requests of the current machine.  Since a machine can have several addresses (one per hardware network interface), specifying a single address would restrict access to the service to those clients which specified the address of that interface.  By specifying INADDR_ANY, the server can arrange to service clients from all interfaces. 

When a socket address is bound, the networking system checks for an interface with the address specified on the current machine (unless, of course, a wildcard address is specified), and returns an error EADDRNOTAVAIL if no such interface is found. 

The local port address specified in a bind(2) call is restricted to be greater than IPPORT_RESERVED (=1024, in <netinet/in.h>) unless the creating process is running as the super-user, providing a space of protected port numbers. The local port address is also required to not be in use in order for it to be assigned.  This is checked by looking for another socket of the same type which has the same local address and local port number.  If such a socket already exists, you will not be able to create another socket at the same address, and will instead get the error EADDRINUSE. If the local port address is specified as 0, then the system picks a unique port address not less than IPPORT_RESERVED and assigns it to the port.  A unique local port address is also picked for a socket which is not bound but which is used with connect(2) or sendto(2); this allows tcp(4P) connections to be made by simply doing socket(2) and then connect(2) in the case where the local port address is not significant; it is defaulted by the system. Similarly if you are sending datagrams with udp(4P) and do not care which port they come from, you can just do socket(2) and sendto(2) and let the system pick a port number.

Let us say that two sockets are incompatible if they have the same port number, are not conected to other sockets, and do not have different local host addresses.  (It is possible to have two sockets with the same port number and different local host addresses because a machine may have several local addresses from its different network interfaces.)  The Internet system does not allow such incompatible sockets to exist on a single machine.  Consider a socket which has a specific local host and local port number on the current machine.  If another process tries to create a socket with a wildcard local host address and the same port number then that request will be denied.  For connection based sockets this prevents these two sockets from attempting to connect to the same foreign host/socket, and thereby causing great havoc.  For connectionless sockets this prevents the dilemma which would result from trying to determine who to deliver an incoming datagram to (since more than one socket could match an address given on a datagram).  The same restriction applies if the wildcard socket exists first.  (If both sockets are wildcard, then the normal restrictions on duplicate addresses apply.) 

A socket option SO_REUSEADDR exists to allow incompatible sockets to be created.  This option is needed to implement the File Transfer Protocol (FTP) which requires that a connection be made from an existing port number (the port number of its primary connection) to a different port number on the same remote host.  The danger here is that the user would attempt to connect this second port to the same remote host/port that the primary connection was using.  In using SO_REUSEADDR the user is pledging not to do this, since this will cause the first connection to abort. 

When a connect(2) is done, the Internet system first checks that the socket is not already connected.  If does not allow connections to port number 0 on another host, nor does it allow connections to a wildcard host (sin_addr.s_addr==INADDR_ANY); attempts to do this yield EADDRINUSE. If the socket from which the connection is being made currently has a wildcard local address (either because it was bound to a specific port with a wildcard address, or was never subjected to bind(2)), then the system picks a local Internet address for the socket from the set of addresses of interfaces on the local machine. If there is an interface on the local machine on the same network as the machine being connected to, then that address is used. Otherwise, the “first” local network interface is used (this is the one that prints out first in “netstat −i”; see netstat(8)). Although it is not supposed to matter which interface address is used, in practice it would probably be better to select the address of the interface through which the packets are to be routed.  This is not currently done (as it would involve a fair amount of additional overhead for datagram transmission).

PROTOCOLS

The Internet protocol family supported by the operating system is comprised of the Internet Datagram Protocol (IP) ip(4P), Address Resolution Protocol (ARP) arp(4P), Internet Control Message Protocol (ICMP) icmp(4P), Transmission Control Protocol (TCP) tcp(4P), and User Datagram Protocol (UDP) udp(4P).

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; see ip(4P). The ICMP message protocol is most often used by the kernel to handle and report errors in protocol processing; it is, however, accessible to user programs. The ARP protocol is used to translate 32-bit Internet host numbers into the 48-bit addresses needed for an Ethernet.

SEE ALSO

intro(3N), byteorder(3N), gethostent(3N), getnetent(3N), getprotoent(3N), getservent(3N), inet(3N), arp(4P), tcp(4P), udp(4P), ip(4P)
Internet Protocol Transition Workbook, Network Information Center, SRI (Sun 800-1056-01)
Internet Protocol Implementation Guide, Network Information Center, SRI (Sun 800-1055-01)
A 4.2BSD Interprocess Communication Primer

Sun Release 3.2  —  Last change: 16 September 1985

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026