133 "urgent" with the MSG_OOB flag to send(3SOCKET). This sets an "urgent
134 pointer" pointing to this byte in the TCP stream. The receiver on the
135 other side of the stream is notified of the urgent data by a SIGURG
136 signal. The SIOCATMARK ioctl(2) request returns a value indicating
137 whether the stream is at the urgent mark. Because the system never
138 returns data across the urgent mark in a single read(2) call, it is
139 possible to advance to the urgent data in a simple loop which reads data,
140 testing the socket with the SIOCATMARK ioctl() request, until it reaches
141 the mark.
142
143 Congestion Control
144 TCP follows the congestion control algorithm described in RFC 2581, and
145 also supports the initial congestion window (cwnd) changes in RFC 3390.
146 The initial cwnd calculation can be overridden by the socket option
147 TCP_INIT_CWND. An application can use this option to set the initial
148 cwnd to a specified number of TCP segments. This applies to the cases
149 when the connection first starts and restarts after an idle period. The
150 process must have the PRIV_SYS_NET_CONFIG privilege if it wants to
151 specify a number greater than that calculated by RFC 3390.
152
153 TCP Keep-Alive
154 Since TCP determines whether a remote peer is no longer reachable by
155 timing out waiting for acknowledgements, a host that never sends any new
156 data may never notice a peer that has gone away. While consumers can
157 avoid this problem by sending their own periodic heartbeat messages
158 (Transport Layer Security does this, for example), TCP describes an
159 optional keep-alive mechanism in RFC 1122. Applications can enable it
160 using the socket-level option SO_KEEPALIVE. When enabled, the first
161 keep-alive probe is sent out after a TCP connection is idle for two
162 hours. If the peer does not respond to the probe within eight minutes,
163 the TCP connection is aborted. An application can alter the probe
164 behavior using the following TCP-level socket options:
165
166 TCP_KEEPALIVE_THRESHOLD
167 Determines the interval for sending the first
168 probe. The option value is specified as an
169 unsigned integer in milliseconds. The system
170 default is controlled by the TCP ndd parameter
171 tcp_keepalive_interval. The minimum value is ten
172 seconds. The maximum is ten days, while the
|
133 "urgent" with the MSG_OOB flag to send(3SOCKET). This sets an "urgent
134 pointer" pointing to this byte in the TCP stream. The receiver on the
135 other side of the stream is notified of the urgent data by a SIGURG
136 signal. The SIOCATMARK ioctl(2) request returns a value indicating
137 whether the stream is at the urgent mark. Because the system never
138 returns data across the urgent mark in a single read(2) call, it is
139 possible to advance to the urgent data in a simple loop which reads data,
140 testing the socket with the SIOCATMARK ioctl() request, until it reaches
141 the mark.
142
143 Congestion Control
144 TCP follows the congestion control algorithm described in RFC 2581, and
145 also supports the initial congestion window (cwnd) changes in RFC 3390.
146 The initial cwnd calculation can be overridden by the socket option
147 TCP_INIT_CWND. An application can use this option to set the initial
148 cwnd to a specified number of TCP segments. This applies to the cases
149 when the connection first starts and restarts after an idle period. The
150 process must have the PRIV_SYS_NET_CONFIG privilege if it wants to
151 specify a number greater than that calculated by RFC 3390.
152
153 The operating system also provides alternative algorithms that may be
154 more appropriate for your application, including the CUBIC congestion
155 control algorithm described in RFC 8312. These can be configured system-
156 wide using ipadm(1M), or on a per-connection basis with the TCP-level
157 socket option TCP_CONGESTION, whose argument is the name of the algorithm
158 to use (for example "cubic"). If the requested algorithm does not exist,
159 then setsockopt() will fail, and errno will be set to ENOENT.
160
161 TCP Keep-Alive
162 Since TCP determines whether a remote peer is no longer reachable by
163 timing out waiting for acknowledgements, a host that never sends any new
164 data may never notice a peer that has gone away. While consumers can
165 avoid this problem by sending their own periodic heartbeat messages
166 (Transport Layer Security does this, for example), TCP describes an
167 optional keep-alive mechanism in RFC 1122. Applications can enable it
168 using the socket-level option SO_KEEPALIVE. When enabled, the first
169 keep-alive probe is sent out after a TCP connection is idle for two
170 hours. If the peer does not respond to the probe within eight minutes,
171 the TCP connection is aborted. An application can alter the probe
172 behavior using the following TCP-level socket options:
173
174 TCP_KEEPALIVE_THRESHOLD
175 Determines the interval for sending the first
176 probe. The option value is specified as an
177 unsigned integer in milliseconds. The system
178 default is controlled by the TCP ndd parameter
179 tcp_keepalive_interval. The minimum value is ten
180 seconds. The maximum is ten days, while the
|