Print this page
5850 tcp timestamping behavior changed mid-connection
Reviewed by: Dan McDonald <danmcd@omniti.com>
Reviewed by: Robert Mustacchi <rm@joyent.com>
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/man/man7p/tcp.7p
+++ new/usr/src/man/man7p/tcp.7p
1 1 '\" te
2 2 .\" Copyright (c) 2006, Sun Microsystems, Inc. All Rights Reserved.
3 3 .\" Copyright (c) 2011 Nexenta Systems, Inc. All rights reserved.
4 4 .\" Copyright 1989 AT&T
5 5 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
6 6 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
7 7 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
8 -.TH TCP 7P "May 27, 2014"
8 +.TH TCP 7P "Apr 27, 2015"
9 9 .SH NAME
10 10 tcp, TCP \- Internet Transmission Control Protocol
11 11 .SH SYNOPSIS
12 12 .LP
13 13 .nf
14 14 \fB#include <sys/socket.h>\fR
15 15 .fi
16 16
17 17 .LP
18 18 .nf
19 19 \fB#include <netinet/in.h>\fR
20 20 .fi
21 21
22 22 .LP
23 23 .nf
24 24 \fBs = socket(AF_INET, SOCK_STREAM, 0);\fR
25 25 .fi
26 26
27 27 .LP
28 28 .nf
29 29 \fBs = socket(AF_INET6, SOCK_STREAM, 0);\fR
30 30 .fi
31 31
32 32 .LP
33 33 .nf
34 34 \fBt = t_open("/dev/tcp", O_RDWR);\fR
35 35 .fi
36 36
37 37 .LP
38 38 .nf
39 39 \fBt = t_open("/dev/tcp6", O_RDWR);\fR
40 40 .fi
41 41
42 42 .SH DESCRIPTION
43 43 .sp
44 44 .LP
45 45 \fBTCP\fR is the virtual circuit protocol of the Internet protocol family. It
46 46 provides reliable, flow-controlled, in order, two-way transmission of data. It
47 47 is a byte-stream protocol layered above the Internet Protocol (\fBIP\fR), or
48 48 the Internet Protocol Version 6 (\fBIPv6\fR), the Internet protocol family's
49 49 internetwork datagram delivery protocol.
50 50 .sp
51 51 .LP
52 52 Programs can access \fBTCP\fR using the socket interface as a \fBSOCK_STREAM\fR
53 53 socket type, or using the Transport Level Interface (\fBTLI\fR) where it
54 54 supports the connection-oriented (\fBT_COTS_ORD\fR) service type.
55 55 .sp
56 56 .LP
57 57 \fBTCP\fR uses \fBIP\fR's host-level addressing and adds its own per-host
58 58 collection of "port addresses." The endpoints of a \fBTCP\fR connection are
59 59 identified by the combination of an \fBIP\fR or IPv6 address and a \fBTCP\fR
60 60 port number. Although other protocols, such as the User Datagram Protocol
61 61 (UDP), may use the same host and port address format, the port space of these
62 62 protocols is distinct. See \fBinet\fR(7P) and \fBinet6\fR(7P) for details on
63 63 the common aspects of addressing in the Internet protocol family.
64 64 .sp
65 65 .LP
66 66 Sockets utilizing \fBTCP\fR are either "active" or "passive." Active sockets
67 67 initiate connections to passive sockets. Both types of sockets must have their
68 68 local \fBIP\fR or IPv6 address and \fBTCP\fR port number bound with the
69 69 \fBbind\fR(3SOCKET) system call after the socket is created. By default,
70 70 \fBTCP\fR sockets are active. A passive socket is created by calling the
71 71 \fBlisten\fR(3SOCKET) system call after binding the socket with \fBbind()\fR.
72 72 This establishes a queueing parameter for the passive socket. After this,
73 73 connections to the passive socket can be received with the
74 74 \fBaccept\fR(3SOCKET) system call. Active sockets use the
75 75 \fBconnect\fR(3SOCKET) call after binding to initiate connections.
76 76 .sp
77 77 .LP
78 78 By using the special value \fBINADDR_ANY\fR with \fBIP\fR, or the unspecified
79 79 address (all zeroes) with IPv6, the local \fBIP\fR address can be left
80 80 unspecified in the \fBbind()\fR call by either active or passive \fBTCP\fR
81 81 sockets. This feature is usually used if the local address is either unknown or
82 82 irrelevant. If left unspecified, the local \fBIP\fR or IPv6 address will be
83 83 bound at connection time to the address of the network interface used to
84 84 service the connection.
85 85 .sp
86 86 .LP
87 87 Note that no two TCP sockets can be bound to the same port unless the bound IP
88 88 addresses are different. IPv4 \fBINADDR_ANY\fR and IPv6 unspecified addresses
89 89 compare as equal to any IPv4 or IPv6 address. For example, if a socket is bound
90 90 to \fBINADDR_ANY\fR or unspecified address and port X, no other socket can bind
91 91 to port X, regardless of the binding address. This special consideration of
92 92 \fBINADDR_ANY\fR and unspecified address can be changed using the socket option
93 93 \fBSO_REUSEADDR\fR. If \fBSO_REUSEADDR\fR is set on a socket doing a bind, IPv4
94 94 \fBINADDR_ANY\fR and IPv6 unspecified address do not compare as equal to any IP
95 95 address. This means that as long as the two sockets are not both bound to
96 96 \fBINADDR_ANY\fR/unspecified address or the same IP address, the two sockets
97 97 can be bound to the same port.
98 98 .sp
99 99 .LP
100 100 If an application does not want to allow another socket using the
101 101 \fBSO_REUSEADDR\fR option to bind to a port its socket is bound to, the
102 102 application can set the socket level option \fBSO_EXCLBIND\fR on a socket. The
103 103 option values of 0 and 1 mean enabling and disabling the option respectively.
104 104 Once this option is enabled on a socket, no other socket can be bound to the
105 105 same port.
106 106 .sp
107 107 .LP
108 108 Once a connection has been established, data can be exchanged using the
109 109 \fBread\fR(2) and \fBwrite\fR(2) system calls.
110 110 .sp
111 111 .LP
112 112 Under most circumstances, \fBTCP\fR sends data when it is presented. When
113 113 outstanding data has not yet been acknowledged, \fBTCP\fR gathers small amounts
114 114 of output to be sent in a single packet once an acknowledgement has been
115 115 received. For a small number of clients, such as window systems that send a
116 116 stream of mouse events which receive no replies, this packetization may cause
117 117 significant delays. To circumvent this problem, \fBTCP\fR provides a
118 118 socket-level boolean option, \fBTCP_NODELAY.\fR \fBTCP_NODELAY\fR is defined in
119 119 \fB<netinet/tcp.h>\fR, and is set with \fBsetsockopt\fR(3SOCKET) and tested
120 120 with \fBgetsockopt\fR(3SOCKET). The option level for the \fBsetsockopt()\fR
121 121 call is the protocol number for \fBTCP,\fR available from
122 122 \fBgetprotobyname\fR(3SOCKET).
123 123 .sp
124 124 .LP
125 125 For some applications, it may be desirable for TCP not to send out data unless
126 126 a full TCP segment can be sent. To enable this behavior, an application can use
127 127 the \fBTCP_CORK\fR socket option. When \fBTCP_CORK\fR is set with a non-zero
128 128 value, TCP sends out a full TCP segment only. When \fBTCP_CORK\fR is set to
129 129 zero after it has been enabled, all buffered data is sent out (as permitted by
130 130 the peer's receive window and the current congestion window). \fBTCP_CORK\fR is
131 131 defined in <\fBnetinet/tcp.h\fR>, and is set with \fBsetsockopt\fR(3SOCKET)
132 132 and tested with \fBgetsockopt\fR(3SOCKET). The option level for the
133 133 \fBsetsockopt()\fR call is the protocol number for TCP, available from
134 134 \fBgetprotobyname\fR(3SOCKET).
135 135 .sp
136 136 .LP
137 137 The SO_RCVBUF socket level option can be used to control the window that TCP
138 138 advertises to the peer. IP level options may also be used with TCP. See
139 139 \fBip\fR(7P) and \fBip6\fR(7P).
140 140 .sp
141 141 .LP
142 142 Another socket level option, \fBSO_RCVBUF,\fR can be used to control the window
143 143 that \fBTCP\fR advertises to the peer. \fBIP\fR level options may also be used
144 144 with \fBTCP.\fR See \fBip\fR(7P) and \fBip6\fR(7P).
145 145 .sp
146 146 .LP
147 147 \fBTCP\fR provides an urgent data mechanism, which may be invoked using the
148 148 out-of-band provisions of \fBsend\fR(3SOCKET). The caller may mark one byte as
149 149 "urgent" with the \fBMSG_OOB\fR flag to \fBsend\fR(3SOCKET). This sets an
150 150 "urgent pointer" pointing to this byte in the \fBTCP\fR stream. The receiver on
151 151 the other side of the stream is notified of the urgent data by a \fBSIGURG\fR
152 152 signal. The \fBSIOCATMARK\fR \fBioctl\fR(2) request returns a value indicating
153 153 whether the stream is at the urgent mark. Because the system never returns data
154 154 across the urgent mark in a single \fBread\fR(2) call, it is possible to
155 155 advance to the urgent data in a simple loop which reads data, testing the
156 156 socket with the \fBSIOCATMARK\fR \fBioctl()\fR request, until it reaches the
157 157 mark.
158 158 .sp
159 159 .LP
160 160 Incoming connection requests that include an \fBIP\fR source route option are
161 161 noted, and the reverse source route is used in responding.
162 162 .sp
163 163 .LP
164 164 A checksum over all data helps \fBTCP\fR implement reliability. Using a
165 165 window-based flow control mechanism that makes use of positive
166 166 acknowledgements, sequence numbers, and a retransmission strategy, \fBTCP\fR
167 167 can usually recover when datagrams are damaged, delayed, duplicated or
168 168 delivered out of order by the underlying communication medium.
169 169 .sp
170 170 .LP
171 171 If the local \fBTCP\fR receives no acknowledgements from its peer for a period
172 172 of time, (for example, if the remote machine crashes), the connection is closed
173 173 and an error is returned.
174 174 .sp
175 175 .LP
|
↓ open down ↓ |
157 lines elided |
↑ open up ↑ |
176 176 TCP follows the congestion control algorithm described in \fIRFC 2581\fR, and
177 177 also supports the initial congestion window (cwnd) changes in \fIRFC 3390\fR.
178 178 The initial cwnd calculation can be overridden by the socket option
179 179 TCP_INIT_CWND. An application can use this option to set the initial cwnd to a
180 180 specified number of TCP segments. This applies to the cases when the connection
181 181 first starts and restarts after an idle period. The process must have the
182 182 PRIV_SYS_NET_CONFIG privilege if it wants to specify a number greater than that
183 183 calculated by \fIRFC 3390\fR.
184 184 .sp
185 185 .LP
186 -SunOS supports \fBTCP\fR Extensions for High Performance (\fIRFC 1323\fR) which
187 -includes the window scale and timestamp options, and Protection Against Wrap
188 -Around Sequence Numbers (PAWS). SunOS also supports Selective Acknowledgment
189 -(SACK) capabilities (RFC 2018) and Explicit Congestion Notification (ECN)
190 -mechanism (\fIRFC 3168\fR).
186 +illumos supports \fBTCP\fR Extensions for High Performance (\fIRFC 7323\fR)
187 +which includes the window scale and timestamp options, and Protection Against
188 +Wrap Around Sequence Numbers (PAWS). Note that if timestamps are negotiated on
189 +a connection, received segments without timestamps on that connection are
190 +silently dropped per the suggestion in the RFC. illumos also supports Selective
191 +Acknowledgment (SACK) capabilities (RFC 2018) and Explicit Congestion
192 +Notification (ECN) mechanism (\fIRFC 3168\fR).
191 193 .sp
192 194 .LP
193 195 Turn on the window scale option in one of the following ways:
194 196 .RS +4
195 197 .TP
196 198 .ie t \(bu
197 199 .el o
198 200 An application can set \fBSO_SNDBUF\fR or \fBSO_RCVBUF\fR size in the
199 201 \fBsetsockopt()\fR option to be larger than 64K. This must be done \fIbefore\fR
200 202 the program calls \fBlisten()\fR or \fBconnect()\fR, because the window scale
201 203 option is negotiated when the connection is established. Once the connection
202 204 has been made, it is too late to increase the send or receive window beyond the
203 205 default \fBTCP\fR limit of 64K.
204 206 .RE
205 207 .RS +4
206 208 .TP
207 209 .ie t \(bu
208 210 .el o
209 211 For all applications, use \fBndd\fR(1M) to modify the configuration parameter
210 212 \fBtcp_wscale_always\fR. If \fBtcp_wscale_always\fR is set to \fB1\fR, the
211 213 window scale option will always be set when connecting to a remote system. If
212 214 \fBtcp_wscale_always\fR is \fB0,\fR the window scale option will be set only if
213 215 the user has requested a send or receive window larger than 64K. The default
214 216 value of \fBtcp_wscale_always\fR is \fB1\fR.
215 217 .RE
216 218 .RS +4
217 219 .TP
218 220 .ie t \(bu
219 221 .el o
220 222 Regardless of the value of \fBtcp_wscale_always\fR, the window scale option
221 223 will always be included in a connect acknowledgement if the connecting system
222 224 has used the option.
223 225 .RE
224 226 .sp
225 227 .LP
226 228 Turn on \fBSACK\fR capabilities in the following way:
227 229 .RS +4
228 230 .TP
229 231 .ie t \(bu
230 232 .el o
231 233 Use \fBndd\fR to modify the configuration parameter \fBtcp_sack_permitted\fR.
232 234 If \fBtcp_sack_permitted\fR is set to \fB0\fR, \fBTCP\fR will not accept
233 235 \fBSACK\fR or send out \fBSACK\fR information. If \fBtcp_sack_permitted\fR is
234 236 set to \fB1\fR, \fBTCP\fR will not initiate a connection with \fBSACK\fR
235 237 permitted option in the \fBSYN\fR segment, but will respond with \fBSACK\fR
236 238 permitted option in the \fBSYN|ACK\fR segment if an incoming connection request
237 239 has the \fBSACK \fR permitted option. This means that \fBTCP\fR will only
238 240 accept \fBSACK\fR information if the other side of the connection also accepts
239 241 \fBSACK\fR information. If \fBtcp_sack_permitted\fR is set to \fB2\fR, it will
240 242 both initiate and accept connections with \fBSACK\fR information. The default
241 243 for \fBtcp_sack_permitted\fR is \fB2\fR (active enabled).
242 244 .RE
243 245 .sp
244 246 .LP
245 247 Turn on \fBTCP ECN\fR mechanism in the following way:
246 248 .RS +4
247 249 .TP
248 250 .ie t \(bu
249 251 .el o
250 252 Use \fBndd\fR to modify the configuration parameter \fBtcp_ecn_permitted\fR. If
251 253 \fBtcp_ecn_permitted\fR is set to \fB0\fR, \fBTCP\fR will not negotiate with a
252 254 peer that supports \fBECN\fR mechanism. If \fBtcp_ecn_permitted\fR is set to
253 255 \fB1\fR when initiating a connection, TCP will not tell a peer that it supports
254 256 ECN mechanism. However, it will tell a peer that it supports \fBECN\fR
255 257 mechanism when accepting a new incoming connection request if the peer
256 258 indicates that it supports \fBECN\fR mechanism in the SYN segment. If
257 259 tcp_ecn_permitted is set to 2, in addition to negotiating with a peer on ECN
258 260 mechanism when accepting connections, TCP will indicate in the outgoing SYN
259 261 segment that it supports \fBECN\fR mechanism when \fBTCP\fR makes active
260 262 outgoing connections. The default for \fBtcp_ecn_permitted\fR is 1.
261 263 .RE
262 264 .sp
263 265 .LP
264 266 Turn on the timestamp option in the following way:
265 267 .RS +4
266 268 .TP
267 269 .ie t \(bu
268 270 .el o
269 271 Use \fBndd\fR to modify the configuration parameter \fBtcp_tstamp_always\fR. If
270 272 \fBtcp_tstamp_always\fR is \fB1\fR, the timestamp option will always be set
271 273 when connecting to a remote machine. If \fBtcp_tstamp_always\fR is \fB0\fR, the
272 274 timestamp option will not be set when connecting to a remote system. The
273 275 default for \fBtcp_tstamp_always\fR is \fB0\fR.
274 276 .RE
275 277 .RS +4
276 278 .TP
277 279 .ie t \(bu
278 280 .el o
279 281 Regardless of the value of \fBtcp_tstamp_always\fR, the timestamp option will
280 282 always be included in a connect acknowledgement (and all succeeding packets) if
281 283 the connecting system has used the timestamp option.
282 284 .RE
283 285 .sp
284 286 .LP
285 287 Use the following procedure to turn on the timestamp option only when the
286 288 window scale option is in effect:
287 289 .RS +4
288 290 .TP
289 291 .ie t \(bu
290 292 .el o
291 293 Use \fBndd\fR to modify the configuration parameter \fBtcp_tstamp_if_wscale\fR.
292 294 Setting \fBtcp_tstamp_if_wscale\fR to \fB1\fR will cause the timestamp option
293 295 to be set when connecting to a remote system, if the window scale option has
294 296 been set. If \fBtcp_tstamp_if_wscale\fR is \fB0\fR, the timestamp option will
295 297 not be set when connecting to a remote system. The default for
296 298 \fBtcp_tstamp_if_wscale\fR is \fB1\fR.
297 299 .RE
298 300 .sp
299 301 .LP
300 302 Protection Against Wrap Around Sequence Numbers (PAWS) is always used when the
301 303 timestamp option is set.
302 304 .sp
303 305 .LP
304 306 SunOS also supports multiple methods of generating initial sequence numbers.
305 307 One of these methods is the improved technique suggested in \fBRFC\fR 1948. We
306 308 \fBHIGHLY\fR recommend that you set sequence number generation parameters as
307 309 close to boot time as possible. This prevents sequence number problems on
308 310 connections that use the same connection-ID as ones that used a different
309 311 sequence number generation. The \fBsvc:/network/initial:default\fR service
310 312 configures the initial sequence number generation. The service reads the value
311 313 contained in the configuration file \fB/etc/default/inetinit\fR to determine
312 314 which method to use.
313 315 .sp
314 316 .LP
315 317 The \fB/etc/default/inetinit\fR file is an unstable interface, and may change
316 318 in future releases.
317 319 .sp
318 320 .LP
319 321 \fBTCP\fR may be configured to report some information on connections that
320 322 terminate by means of an \fBRST\fR packet. By default, no logging is done. If
321 323 the \fBndd\fR(1M) parameter \fItcp_trace\fR is set to 1, then trace data is
322 324 collected for all new connections established after that time.
323 325 .sp
324 326 .LP
325 327 The trace data consists of the \fBTCP\fR headers and \fBIP\fR source and
326 328 destination addresses of the last few packets sent in each direction before RST
327 329 occurred. Those packets are logged in a series of \fBstrlog\fR(9F) calls. This
328 330 trace facility has a very low overhead, and so is superior to such utilities as
329 331 \fBsnoop\fR(1M) for non-intrusive debugging for connections terminating by
330 332 means of an \fBRST\fR.
331 333 .sp
332 334 .LP
333 335 SunOS supports the keep-alive mechanism described in \fIRFC 1122\fR. It is
334 336 enabled using the socket option SO_KEEPALIVE. When enabled, the first
335 337 keep-alive probe is sent out after a TCP is idle for two hours If the peer does
336 338 not respond to the probe within eight minutes, the TCP connection is aborted.
337 339 You can alter the interval for sending out the first probe using the socket
338 340 option TCP_KEEPALIVE_THRESHOLD. The option value is an unsigned integer in
339 341 milliseconds. The system default is controlled by the TCP ndd parameter
340 342 tcp_keepalive_interval. The minimum value is ten seconds. The maximum is ten
341 343 days, while the default is two hours. If you receive no response to the probe,
342 344 you can use the TCP_KEEPALIVE_ABORT_THRESHOLD socket option to change the time
343 345 threshold for aborting a TCP connection. The option value is an unsigned
344 346 integer in milliseconds. The value zero indicates that TCP should never time
345 347 out and abort the connection when probing. The system default is controlled by
346 348 the TCP ndd parameter tcp_keepalive_abort_interval. The default is eight
347 349 minutes.
348 350 .sp
349 351 .LP
350 352 socket options TCP_KEEPIDLE, TCP_KEEPCNT and TCP_KEEPINTVL are also supported
351 353 for compatibility with other Unix Flavors. TCP_KEEPIDLE option specifies the
352 354 interval in seconds for sending out the first keep-alive probe. TCP_KEEPCNT
353 355 specifies the number of keep-alive probes to be sent before aborting the
354 356 connection in the event of no response from peer. TCP_KEEPINTVL specifies the
355 357 interval in seconds between successive keep-alive probes.
356 358 .SH SEE ALSO
357 359 .sp
358 360 .LP
359 361 \fBsvcs\fR(1), \fBndd\fR(1M), \fBioctl\fR(2), \fBread\fR(2), \fBsvcadm\fR(1M),
360 362 \fBwrite\fR(2), \fBaccept\fR(3SOCKET), \fBbind\fR(3SOCKET),
361 363 \fBconnect\fR(3SOCKET), \fBgetprotobyname\fR(3SOCKET),
362 364 \fBgetsockopt\fR(3SOCKET), \fBlisten\fR(3SOCKET), \fBsend\fR(3SOCKET),
363 365 \fBsmf\fR(5), \fBinet\fR(7P), \fBinet6\fR(7P), \fBip\fR(7P), \fBip6\fR(7P)
364 366 .sp
365 367 .LP
366 368 Ramakrishnan, K., Floyd, S., Black, D., RFC 3168, \fIThe Addition of Explicit
367 369 Congestion Notification (ECN) to IP\fR, September 2001.
368 370 .sp
|
↓ open down ↓ |
168 lines elided |
↑ open up ↑ |
369 371 .LP
370 372 Mathias, M. and Hahdavi, J. Pittsburgh Supercomputing Center; Ford, S. Lawrence
371 373 Berkeley National Laboratory; Romanow, A. Sun Microsystems, Inc. \fIRFC 2018,
372 374 TCP Selective Acknowledgement Options\fR, October 1996.
373 375 .sp
374 376 .LP
375 377 Bellovin, S., \fIRFC 1948, Defending Against Sequence Number Attacks\fR, May
376 378 1996.
377 379 .sp
378 380 .LP
379 -Jacobson, V., Braden, R., and Borman, D., \fIRFC 1323, TCP Extensions for High
380 -Performance\fR, May 1992.
381 +D. Borman, B. Braden, V. Jacobson and R. Scheffenegger, Ed., \fIRFC 7323, TCP
382 +Extensions for High Performance\fR, September 2014.
381 383 .sp
382 384 .LP
383 385 Postel, Jon, \fIRFC 793, Transmission Control Protocol - DARPA Internet Program
384 386 Protocol Specification\fR, Network Information Center, SRI International, Menlo
385 387 Park, CA., September 1981.
386 388 .SH DIAGNOSTICS
387 389 .sp
388 390 .LP
389 391 A socket operation may fail if:
390 392 .sp
391 393 .ne 2
392 394 .na
393 395 \fB\fBEISCONN\fR\fR
394 396 .ad
395 397 .RS 17n
396 398 A \fBconnect()\fR operation was attempted on a socket on which a
397 399 \fBconnect()\fR operation had already been performed.
398 400 .RE
399 401
400 402 .sp
401 403 .ne 2
402 404 .na
403 405 \fB\fBETIMEDOUT\fR\fR
404 406 .ad
405 407 .RS 17n
406 408 A connection was dropped due to excessive retransmissions.
407 409 .RE
408 410
409 411 .sp
410 412 .ne 2
411 413 .na
412 414 \fB\fBECONNRESET\fR\fR
413 415 .ad
414 416 .RS 17n
415 417 The remote peer forced the connection to be closed (usually because the remote
416 418 machine has lost state information about the connection due to a crash).
417 419 .RE
418 420
419 421 .sp
420 422 .ne 2
421 423 .na
422 424 \fB\fBECONNREFUSED\fR\fR
423 425 .ad
424 426 .RS 17n
425 427 The remote peer actively refused connection establishment (usually because no
426 428 process is listening to the port).
427 429 .RE
428 430
429 431 .sp
430 432 .ne 2
431 433 .na
432 434 \fB\fBEADDRINUSE\fR\fR
433 435 .ad
434 436 .RS 17n
435 437 A \fBbind()\fR operation was attempted on a socket with a network address/port
436 438 pair that has already been bound to another socket.
437 439 .RE
438 440
439 441 .sp
440 442 .ne 2
441 443 .na
442 444 \fB\fBEADDRNOTAVAIL\fR\fR
443 445 .ad
444 446 .RS 17n
445 447 A \fBbind()\fR operation was attempted on a socket with a network address for
446 448 which no network interface exists.
447 449 .RE
448 450
449 451 .sp
450 452 .ne 2
451 453 .na
452 454 \fB\fBEACCES\fR\fR
453 455 .ad
454 456 .RS 17n
455 457 A \fBbind()\fR operation was attempted with a "reserved" port number and the
456 458 effective user \fBID\fR of the process was not the privileged user.
457 459 .RE
458 460
459 461 .sp
460 462 .ne 2
461 463 .na
462 464 \fB\fBENOBUFS\fR\fR
463 465 .ad
464 466 .RS 17n
465 467 The system ran out of memory for internal data structures.
466 468 .RE
467 469
468 470 .SH NOTES
469 471 .sp
470 472 .LP
471 473 The \fBtcp\fR service is managed by the service management facility,
472 474 \fBsmf\fR(5), under the service identifier:
473 475 .sp
474 476 .in +2
475 477 .nf
476 478 svc:/network/initial:default
477 479 .fi
478 480 .in -2
479 481 .sp
480 482
481 483 .sp
482 484 .LP
483 485 Administrative actions on this service, such as enabling, disabling, or
484 486 requesting restart, can be performed using \fBsvcadm\fR(1M). The service's
485 487 status can be queried using the \fBsvcs\fR(1) command.
|
↓ open down ↓ |
95 lines elided |
↑ open up ↑ |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX