svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
inet(4p)
inet(4P) Network Protocols inet(4P)
NAME
inet - Internet protocol family
SYNOPSIS
#include <sys/types.h>
#include <netinet/in.h>
DESCRIPTION
The Internet protocol family implements a collection of protocols which
are centered around the Internet Protocol ("IP") and which share a com‐
mon address format. The Internet family protocols can be accessed using
the socket interface, where they support the SOCK_STREAM, SOCK_DGRAM,
and SOCK_RAW socket types, or the Transport Level Interface (TLI),
where they support the connectionless (T_CLTS) and connection oriented
(T_COTS_ORD) service types.
PROTOCOLS
The Internet protocol family is comprised of the Internet Protocol
("IP"), the Address Resolution Protocol ("ARP"), the Internet Control
Message Protocol ("ICMP"), the Transmission Control Protocol ("TCP"),
and the User Datagram Protocol ("UDP").
Two versions of the Internet Protocol are supported, the previous ver‐
sion 4 ("IPv4"), and the current version 6 ("IPv6"). This manual page
documents IPv4. See the inet6(4P) manual page for details of IPv6.
TCP supports the socket interface's SOCK_STREAM abstraction and TLI's
T_COTS_ORD service type. UDP supports the SOCK_DGRAM socket abstraction
and the TLI T_CLTS service type. See tcp(4P) and udp(4P). A direct in‐
terface to IP is available using both TLI and the socket interface (see
ip(4P)). ICMP is used by the kernel to handle and report errors in pro‐
tocol processing. It is also accessible to user programs (see
icmp(4P)). ARP is used to translate 32-bit IP addresses into 48-bit
Ethernet addresses. See arp(4P).
The 32-bit IPv4 address is divided into network number and host number
parts, using a network interface mask with bits set to 1 for the net‐
work portion and bits set to 0 for the host portion. Sites with multi‐
ple IP networks may chose to use subnet addressing to split their net‐
work address range into smaller units. Within a subnet, each subnet ap‐
pears to be an individual network. Externally, the entire cluster ap‐
pears to be a single, uniform network requiring only a single routing
entry. Subnet addressing is enabled and examined by the following
ioctl(2) commands. They have the same form as the SIOCSIFADDR command.
SIOCSIFNETMASK Set interface network mask. The network mask defines
the network part of the address.
SIOCGIFNETMASK Get interface network mask.
ADDRESSING
IP addresses are four byte quantities, stored in network byte order. IP
addresses should be manipulated using the byte order conversion rou‐
tines. See byteorder(3C).
Addresses in the Internet protocol family use the sockaddr_in struc‐
ture, which has the following members:
short sin_family;
ushort_t sin_port;
struct in_addr sin_addr;
char sin_zero[8];
Library routines are provided to manipulate structures of this form;
See inet(3C).
The sin_addr field of the sockaddr_in structure specifies a local or
remote IP address. Each network interface has its own unique IP ad‐
dress. The special value INADDR_ANY may be used in this field to per‐
form "wildcard" matching. Given in a bind(3C) call, this value leaves
the local IP address of the socket unspecified, so that the socket will
receive connections or messages directed at any of the valid IP ad‐
dresses of the system. This can prove useful when a process neither
knows nor cares what the local IP address is or when a process wishes
to receive requests using all of its network interfaces. The sock‐
addr_in structure given in the bind(3C) call must specify an in_addr
value of either INADDR_ANY or one of the system's valid IP addresses.
Requests to bind any other address will return the error EADDRNOTAVAIL.
When a connect(3C) call is made for a socket that has a wildcard local
address, the system sets the sin_addr field of the socket to the IP ad‐
dress of the network interface that the packets for that connection are
routed through.
The sin_port field of the sockaddr_in structure specifies a port number
used by TCP or UDP. The local port address specified in a bind(3C) call
is restricted to be greater than or equal to smallest-nonpriv-port, and
not one of the extra-priv-ports, unless the process has the
PRIV_NET_PRIVADDR privilege asserted, as described in the privileges(7)
manual page. The smallest-nonpriv-port and extra-priv-ports properties
may be modified or queried via the ipadm(8) command. The default value
for smallest-nonpriv-port is the constant IPPORT_RESERVED (defined in
<netinet/in.h>). In addition, the local port address must not be in use
by any socket of same address family and type. Requests to bind sockets
to port numbers being used by other sockets return the error EADDRI‐
NUSE. If the local port address is specified as 0, then the system
picks a unique port address in the range (smallest-anon-port, largest-
anon-port), where the smallest-anon-port and largest-anon-port proper‐
ties may be modified or queried via the ipadm(8) command. A unique lo‐
cal port address is also picked when a socket which is not bound is
used in a connect(3C) or sendto(3C) call. This allows programs which do
not care which local port number is used to set up TCP connections by
simply calling socket(3C) and then connect(3C), and to send UDP data‐
grams with a socket(3C) call followed by a sendto(3C) call.
Although this implementation restricts sockets to unique local port
numbers, TCP allows multiple simultaneous connections involving the
same local port number so long as the remote IP addresses or port num‐
bers are different for each connection. Programs may explicitly over‐
ride the socket restriction by setting the SO_REUSEADDR socket option
with setsockopt(3C)).
TLI applies somewhat different semantics to the binding of local port
numbers. These semantics apply when Internet family protocols are used
using the TLI.
SEE ALSO
ioctl(2), bind(3C), byteorder(3C), connect(3C), getaddrinfo(3C),
getnameinfo(3C), getnetbyname(3C), getprotobyname(3C),
getservbyname(3C), inet(3C), sendto(3C), setsockopt(3C), socket(3C),
arp(4P), icmp(4P), inet6(4P), ip(4P), tcp(4P), udp(4P), privileges(7),
ipadm(8)
Internet Engineering Task Force Standards:
https://www.ietf.org/standards/
NOTES
The Internet protocol support is subject to change as the Internet pro‐
tocols develop. Users should not depend on details of the current im‐
plementation, but rather the services exported.
Oracle Solaris 11.4 2 Feb 2021 inet(4P)