Print this page
11554 Want TCP_CONGESTION socket option
Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/man/man7p/tcp.7p.man.txt
+++ new/usr/src/man/man7p/tcp.7p.man.txt
1 1 TCP(7P) Protocols TCP(7P)
2 2
3 3 NAME
4 4 tcp, TCP - Internet Transmission Control Protocol
5 5
6 6 SYNOPSIS
7 7 #include <sys/socket.h>
8 8 #include <netinet/in.h>
9 9 #include <netinet/tcp.h>
10 10
11 11 s = socket(AF_INET, SOCK_STREAM, 0);
12 12 s = socket(AF_INET6, SOCK_STREAM, 0);
13 13 t = t_open("/dev/tcp", O_RDWR);
14 14 t = t_open("/dev/tcp6", O_RDWR);
15 15
16 16 DESCRIPTION
17 17 TCP is the virtual circuit protocol of the Internet protocol family. It
18 18 provides reliable, flow-controlled, in-order, two-way transmission of
19 19 data. It is a byte-stream protocol layered above the Internet Protocol
20 20 (IP), or the Internet Protocol Version 6 (IPv6), the Internet protocol
21 21 family's internetwork datagram delivery protocol.
22 22
23 23 Programs can access TCP using the socket interface as a SOCK_STREAM
24 24 socket type, or using the Transport Level Interface (TLI) where it
25 25 supports the connection-oriented (BT_COTS_ORD) service type.
26 26
27 27 A checksum over all data helps TCP provide reliable communication. Using
28 28 a window-based flow control mechanism that makes use of positive
29 29 acknowledgements, sequence numbers, and a retransmission strategy, TCP
30 30 can usually recover when datagrams are damaged, delayed, duplicated or
31 31 delivered out of order by the underlying medium.
32 32
33 33 TCP provides several socket options, defined in <netinet/tcp.h> and
34 34 described throughout this document, which may be set using
35 35 setsockopt(3SOCKET) and read using getsockopt(3SOCKET). The level
36 36 argument for these calls is the protocol number for TCP, available from
37 37 getprotobyname(3SOCKET). IP level options may also be used with TCP.
38 38 See ip(7P) and ip6(7P).
39 39
40 40 Listening And Connecting
41 41 TCP uses IP's host-level addressing and adds its own per-host collection
42 42 of "port addresses". The endpoints of a TCP connection are identified by
43 43 the combination of an IPv4 or IPv6 address and a TCP port number.
44 44 Although other protocols, such as the User Datagram Protocol (UDP), may
45 45 use the same host and port address format, the port space of these
46 46 protocols is distinct. See inet(7P) and inet6(7P) for details on the
47 47 common aspects of addressing in the Internet protocol family.
48 48
49 49 Sockets utilizing TCP are either "active" or "passive". Active sockets
50 50 initiate connections to passive sockets. Passive sockets must have their
51 51 local IPv4 or IPv6 address and TCP port number bound with the
52 52 bind(3SOCKET) system call after the socket is created. If an active
53 53 socket has not been bound by the time connect(3SOCKET) is called, then
54 54 the operating system will choose a local address and port for the
55 55 application. By default, TCP sockets are active. A passive socket is
56 56 created by calling the listen(3SOCKET) system call after binding, which
57 57 establishes a queueing parameter for the passive socket. Connections to
58 58 the passive socket can then be received using the accept(3SOCKET) system
59 59 call. Active sockets use the connect(3SOCKET) call after binding to
60 60 initiate connections.
61 61
62 62 If incoming connection requests include an IP source route option, then
63 63 the reverse source route will be used when responding.
64 64
65 65 By using the special value INADDR_ANY with IPv4, or the unspecified
66 66 address (all zeroes) with IPv6, the local IP address can be left
67 67 unspecified in the bind() call by either active or passive TCP sockets.
68 68 This feature is usually used if the local address is either unknown or
69 69 irrelevant. If left unspecified, the local IP address will be bound at
70 70 connection time to the address of the network interface used to service
71 71 the connection. For passive sockets, this is the destination address
72 72 used by the connecting peer. For active sockets, this is usually an
73 73 address on the same subnet as the destination or default gateway address,
74 74 although the rules can be more complex. See Source Address Selection in
75 75 inet6(7P) for a detailed discussion of how this works in IPv6.
76 76
77 77 Note that no two TCP sockets can be bound to the same port unless the
78 78 bound IP addresses are different. IPv4 INADDR_ANY and IPv6 unspecified
79 79 addresses compare as equal to any IPv4 or IPv6 address. For example, if
80 80 a socket is bound to INADDR_ANY or the unspecified address and port N, no
81 81 other socket can bind to port N, regardless of the binding address. This
82 82 special consideration of INADDR_ANY and the unspecified address can be
83 83 changed using the socket option SO_REUSEADDR. If SO_REUSEADDR is set on
84 84 a socket doing a bind, IPv4 INADDR_ANY and the IPv6 unspecified address
85 85 do not compare as equal to any IP address. This means that as long as
86 86 the two sockets are not both bound to INADDR_ANY, the unspecified
87 87 address, or the same IP address, then the two sockets can be bound to the
88 88 same port.
89 89
90 90 If an application does not want to allow another socket using the
91 91 SO_REUSEADDR option to bind to a port its socket is bound to, the
92 92 application can set the socket-level (SOL_SOCKET) option SO_EXCLBIND on a
93 93 socket. The option values of 0 and 1 mean enabling and disabling the
94 94 option respectively. Once this option is enabled on a socket, no other
95 95 socket can be bound to the same port.
96 96
97 97 Sending And Receiving Data
98 98 Once a connection has been established, data can be exchanged using the
99 99 read(2) and write(2) system calls. If, after sending data, the local TCP
100 100 receives no acknowledgements from its peer for a period of time (for
101 101 example, if the remote machine crashes), the connection is closed and an
102 102 error is returned.
103 103
104 104 When a peer is sending data, it will only send up to the advertised
105 105 "receive window", which is determined by how much more data the recipient
106 106 can fit in its buffer. Applications can use the socket-level option
107 107 SO_RCVBUF to increase or decrease the receive buffer size. Similarly,
108 108 the socket-level option SO_SNDBUF can be used to allow TCP to buffer more
109 109 unacknowledged and unsent data locally.
110 110
111 111 Under most circumstances, TCP will send data when it is written by the
112 112 application. When outstanding data has not yet been acknowledged,
113 113 though, TCP will gather small amounts of output to be sent as a single
114 114 packet once an acknowledgement has been received. Usually referred to as
115 115 Nagle's Algorithm (RFC 896), this behavior helps prevent flooding the
116 116 network with many small packets.
117 117
118 118 However, for some highly interactive clients (such as remote shells or
119 119 windowing systems that send a stream of keypresses or mouse events), this
120 120 batching may cause significant delays. To disable this behavior, TCP
121 121 provides a boolean socket option, TCP_NODELAY.
122 122
123 123 Conversely, for other applications, it may be desirable for TCP not to
124 124 send out any data until a full TCP segment can be sent. To enable this
125 125 behavior, an application can use the TCP-level socket option TCP_CORK.
126 126 When set to a non-zero value, TCP will only send out a full TCP segment.
127 127 When TCP_CORK is set to zero after it has been enabled, all currently
128 128 buffered data is sent out (as permitted by the peer's receive window and
129 129 the current congestion window).
130 130
131 131 TCP provides an urgent data mechanism, which may be invoked using the
132 132 out-of-band provisions of send(3SOCKET). The caller may mark one byte as
133 133 "urgent" with the MSG_OOB flag to send(3SOCKET). This sets an "urgent
134 134 pointer" pointing to this byte in the TCP stream. The receiver on the
135 135 other side of the stream is notified of the urgent data by a SIGURG
136 136 signal. The SIOCATMARK ioctl(2) request returns a value indicating
137 137 whether the stream is at the urgent mark. Because the system never
138 138 returns data across the urgent mark in a single read(2) call, it is
139 139 possible to advance to the urgent data in a simple loop which reads data,
140 140 testing the socket with the SIOCATMARK ioctl() request, until it reaches
141 141 the mark.
142 142
|
↓ open down ↓ |
142 lines elided |
↑ open up ↑ |
143 143 Congestion Control
144 144 TCP follows the congestion control algorithm described in RFC 2581, and
145 145 also supports the initial congestion window (cwnd) changes in RFC 3390.
146 146 The initial cwnd calculation can be overridden by the socket option
147 147 TCP_INIT_CWND. An application can use this option to set the initial
148 148 cwnd to a specified number of TCP segments. This applies to the cases
149 149 when the connection first starts and restarts after an idle period. The
150 150 process must have the PRIV_SYS_NET_CONFIG privilege if it wants to
151 151 specify a number greater than that calculated by RFC 3390.
152 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 +
153 161 TCP Keep-Alive
154 162 Since TCP determines whether a remote peer is no longer reachable by
155 163 timing out waiting for acknowledgements, a host that never sends any new
156 164 data may never notice a peer that has gone away. While consumers can
157 165 avoid this problem by sending their own periodic heartbeat messages
158 166 (Transport Layer Security does this, for example), TCP describes an
159 167 optional keep-alive mechanism in RFC 1122. Applications can enable it
160 168 using the socket-level option SO_KEEPALIVE. When enabled, the first
161 169 keep-alive probe is sent out after a TCP connection is idle for two
162 170 hours. If the peer does not respond to the probe within eight minutes,
163 171 the TCP connection is aborted. An application can alter the probe
164 172 behavior using the following TCP-level socket options:
165 173
166 174 TCP_KEEPALIVE_THRESHOLD
167 175 Determines the interval for sending the first
168 176 probe. The option value is specified as an
169 177 unsigned integer in milliseconds. The system
170 178 default is controlled by the TCP ndd parameter
171 179 tcp_keepalive_interval. The minimum value is ten
172 180 seconds. The maximum is ten days, while the
173 181 default is two hours.
174 182
175 183 TCP_KEEPALIVE_ABORT_THRESHOLD
176 184 If TCP does not receive a response to the probe,
177 185 then this option determines how long to wait
178 186 before aborting a TCP connection. The option
179 187 value is an unsigned integer in milliseconds.
180 188 The value zero indicates that TCP should never
181 189 time out and abort the connection when probing.
182 190 The system default is controlled by the TCP ndd
183 191 parameter tcp_keepalive_abort_interval. The
184 192 default is eight minutes.
185 193
186 194 TCP_KEEPIDLE This option, like TCP_KEEPALIVE_THRESHOLD,
187 195 determines the interval for sending the first
188 196 probe, except that the option value is an
189 197 unsigned integer in seconds. It is provided
190 198 primarily for compatibility with other Unix
191 199 flavors.
192 200
193 201 TCP_KEEPCNT This option specifies the number of keep-alive
194 202 probes that should be sent without any response
195 203 from the peer before aborting the connection.
196 204
197 205 TCP_KEEPINTVL This option specifies the interval in seconds
198 206 between successive, unacknowledged keep-alive
199 207 probes.
200 208
201 209 Additional Configuration
202 210 illumos supports TCP Extensions for High Performance (RFC 7323) which
203 211 includes the window scale and timestamp options, and Protection Against
204 212 Wrap Around Sequence Numbers (PAWS). Note that if timestamps are
205 213 negotiated on a connection, received segments without timestamps on that
206 214 connection are silently dropped per the suggestion in the RFC. illumos
207 215 also supports Selective Acknowledgment (SACK) capabilities (RFC 2018) and
208 216 Explicit Congestion Notification (ECN) mechanism (RFC 3168).
209 217
210 218 Turn on the window scale option in one of the following ways:
211 219
212 220 o An application can set SO_SNDBUF or SO_RCVBUF size in the
213 221 setsockopt() option to be larger than 64K. This must be done
214 222 before the program calls listen() or connect(), because the
215 223 window scale option is negotiated when the connection is
216 224 established. Once the connection has been made, it is too
217 225 late to increase the send or receive window beyond the
218 226 default TCP limit of 64K.
219 227
220 228 o For all applications, use ndd(1M) to modify the configuration
221 229 parameter tcp_wscale_always. If tcp_wscale_always is set to
222 230 1, the window scale option will always be set when connecting
223 231 to a remote system. If tcp_wscale_always is 0, the window
224 232 scale option will be set only if the user has requested a
225 233 send or receive window larger than 64K. The default value of
226 234 tcp_wscale_always is 1.
227 235
228 236 o Regardless of the value of tcp_wscale_always, the window
229 237 scale option will always be included in a connect
230 238 acknowledgement if the connecting system has used the option.
231 239
232 240 Turn on SACK capabilities in the following way:
233 241
234 242 o Use ndd to modify the configuration parameter
235 243 tcp_sack_permitted. If tcp_sack_permitted is set to 0, TCP
236 244 will not accept SACK or send out SACK information. If
237 245 tcp_sack_permitted is set to 1, TCP will not initiate a
238 246 connection with SACK permitted option in the SYN segment, but
239 247 will respond with SACK permitted option in the SYN|ACK
240 248 segment if an incoming connection request has the SACK
241 249 permitted option. This means that TCP will only accept SACK
242 250 information if the other side of the connection also accepts
243 251 SACK information. If tcp_sack_permitted is set to 2, it will
244 252 both initiate and accept connections with SACK information.
245 253 The default for tcp_sack_permitted is 2 (active enabled).
246 254
247 255 Turn on the TCP ECN mechanism in the following way:
248 256
249 257 o Use ndd to modify the configuration parameter
250 258 tcp_ecn_permitted. If tcp_ecn_permitted is set to 0, then
251 259 TCP will not negotiate with a peer that supports ECN
252 260 mechanism. If tcp_ecn_permitted is set to 1 when initiating
253 261 a connection, TCP will not tell a peer that it supports ECN
254 262 mechanism. However, it will tell a peer that it supports ECN
255 263 mechanism when accepting a new incoming connection request if
256 264 the peer indicates that it supports ECN mechanism in the SYN
257 265 segment. If tcp_ecn_permitted is set to 2, in addition to
258 266 negotiating with a peer on ECN mechanism when accepting
259 267 connections, TCP will indicate in the outgoing SYN segment
260 268 that it supports ECN mechanism when TCP makes active outgoing
261 269 connections. The default for tcp_ecn_permitted is 1.
262 270
263 271 Turn on the timestamp option in the following way:
264 272
265 273 o Use ndd to modify the configuration parameter
266 274 tcp_tstamp_always. If tcp_tstamp_always is 1, the timestamp
267 275 option will always be set when connecting to a remote
268 276 machine. If tcp_tstamp_always is 0, the timestamp option
269 277 will not be set when connecting to a remote system. The
270 278 default for tcp_tstamp_always is 0.
271 279
272 280 o Regardless of the value of tcp_tstamp_always, the timestamp
273 281 option will always be included in a connect acknowledgement
274 282 (and all succeeding packets) if the connecting system has
275 283 used the timestamp option.
276 284
277 285 Use the following procedure to turn on the timestamp option only when the
278 286 window scale option is in effect:
279 287
280 288 o Use ndd to modify the configuration parameter
281 289 tcp_tstamp_if_wscale. Setting tcp_tstamp_if_wscale to 1 will
282 290 cause the timestamp option to be set when connecting to a
283 291 remote system, if the window scale option has been set. If
284 292 tcp_tstamp_if_wscale is 0, the timestamp option will not be
285 293 set when connecting to a remote system. The default for
286 294 tcp_tstamp_if_wscale is 1.
287 295
288 296 Protection Against Wrap Around Sequence Numbers (PAWS) is always used
289 297 when the timestamp option is set.
290 298
291 299 The operating system also supports multiple methods of generating initial
292 300 sequence numbers. One of these methods is the improved technique
293 301 suggested in RFC 1948. We HIGHLY recommend that you set sequence number
294 302 generation parameters as close to boot time as possible. This prevents
295 303 sequence number problems on connections that use the same connection-ID
296 304 as ones that used a different sequence number generation. The
297 305 svc:/network/initial:default service configures the initial sequence
298 306 number generation. The service reads the value contained in the
299 307 configuration file /etc/default/inetinit to determine which method to
300 308 use.
301 309
302 310 The /etc/default/inetinit file is an unstable interface, and may change
303 311 in future releases.
304 312
305 313 EXAMPLES
306 314 Example 1: Connecting to a server
307 315 $ gcc -std=c99 -Wall -lsocket -o client client.c
308 316 $ cat client.c
309 317 #include <sys/socket.h>
310 318 #include <netinet/in.h>
311 319 #include <netinet/tcp.h>
312 320 #include <netdb.h>
313 321 #include <stdio.h>
314 322 #include <string.h>
315 323 #include <unistd.h>
316 324
317 325 int
318 326 main(int argc, char *argv[])
319 327 {
320 328 struct addrinfo hints, *gair, *p;
321 329 int fd, rv, rlen;
322 330 char buf[1024];
323 331 int y = 1;
324 332
325 333 if (argc != 3) {
326 334 fprintf(stderr, "%s <host> <port>\n", argv[0]);
327 335 return (1);
328 336 }
329 337
330 338 memset(&hints, 0, sizeof (hints));
331 339 hints.ai_family = PF_UNSPEC;
332 340 hints.ai_socktype = SOCK_STREAM;
333 341
334 342 if ((rv = getaddrinfo(argv[1], argv[2], &hints, &gair)) != 0) {
335 343 fprintf(stderr, "getaddrinfo() failed: %s\n",
336 344 gai_strerror(rv));
337 345 return (1);
338 346 }
339 347
340 348 for (p = gair; p != NULL; p = p->ai_next) {
341 349 if ((fd = socket(
342 350 p->ai_family,
343 351 p->ai_socktype,
344 352 p->ai_protocol)) == -1) {
345 353 perror("socket() failed");
346 354 continue;
347 355 }
348 356
349 357 if (connect(fd, p->ai_addr, p->ai_addrlen) == -1) {
350 358 close(fd);
351 359 perror("connect() failed");
352 360 continue;
353 361 }
354 362
355 363 break;
356 364 }
357 365
358 366 if (p == NULL) {
359 367 fprintf(stderr, "failed to connect to server\n");
360 368 return (1);
361 369 }
362 370
363 371 freeaddrinfo(gair);
364 372
365 373 if (setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &y,
366 374 sizeof (y)) == -1) {
367 375 perror("setsockopt(SO_KEEPALIVE) failed");
368 376 return (1);
369 377 }
370 378
371 379 while ((rlen = read(fd, buf, sizeof (buf))) > 0) {
372 380 fwrite(buf, rlen, 1, stdout);
373 381 }
374 382
375 383 if (rlen == -1) {
376 384 perror("read() failed");
377 385 }
378 386
379 387 fflush(stdout);
380 388
381 389 if (close(fd) == -1) {
382 390 perror("close() failed");
383 391 }
384 392
385 393 return (0);
386 394 }
387 395 $ ./client 127.0.0.1 8080
388 396 hello
389 397 $ ./client ::1 8080
390 398 hello
391 399
392 400 Example 2: Accepting client connections
393 401 $ gcc -std=c99 -Wall -lsocket -o server server.c
394 402 $ cat server.c
395 403 #include <sys/socket.h>
396 404 #include <netinet/in.h>
397 405 #include <netinet/tcp.h>
398 406 #include <netdb.h>
399 407 #include <stdio.h>
400 408 #include <string.h>
401 409 #include <unistd.h>
402 410 #include <arpa/inet.h>
403 411
404 412 void
405 413 logmsg(struct sockaddr *s, int bytes)
406 414 {
407 415 char dq[INET6_ADDRSTRLEN];
408 416
409 417 switch (s->sa_family) {
410 418 case AF_INET: {
411 419 struct sockaddr_in *s4 = (struct sockaddr_in *)s;
412 420 inet_ntop(AF_INET, &s4->sin_addr, dq, sizeof (dq));
413 421 fprintf(stdout, "sent %d bytes to %s:%d\n",
414 422 bytes, dq, ntohs(s4->sin_port));
415 423 break;
416 424 }
417 425 case AF_INET6: {
418 426 struct sockaddr_in6 *s6 = (struct sockaddr_in6 *)s;
419 427 inet_ntop(AF_INET6, &s6->sin6_addr, dq, sizeof (dq));
420 428 fprintf(stdout, "sent %d bytes to [%s]:%d\n",
421 429 bytes, dq, ntohs(s6->sin6_port));
422 430 break;
423 431 }
424 432 default:
425 433 fprintf(stdout, "sent %d bytes to unknown client\n",
426 434 bytes);
427 435 break;
428 436 }
429 437 }
430 438
431 439 int
432 440 main(int argc, char *argv[])
433 441 {
434 442 struct addrinfo hints, *gair, *p;
435 443 int sfd, cfd;
436 444 int slen, wlen, rv;
437 445
438 446 if (argc != 3) {
439 447 fprintf(stderr, "%s <port> <message>\n", argv[0]);
440 448 return (1);
441 449 }
442 450
443 451 slen = strlen(argv[2]);
444 452
445 453 memset(&hints, 0, sizeof (hints));
446 454 hints.ai_family = PF_UNSPEC;
447 455 hints.ai_socktype = SOCK_STREAM;
448 456 hints.ai_flags = AI_PASSIVE;
449 457
450 458 if ((rv = getaddrinfo(NULL, argv[1], &hints, &gair)) != 0) {
451 459 fprintf(stderr, "getaddrinfo() failed: %s\n",
452 460 gai_strerror(rv));
453 461 return (1);
454 462 }
455 463
456 464 for (p = gair; p != NULL; p = p->ai_next) {
457 465 if ((sfd = socket(
458 466 p->ai_family,
459 467 p->ai_socktype,
460 468 p->ai_protocol)) == -1) {
461 469 perror("socket() failed");
462 470 continue;
463 471 }
464 472
465 473 if (bind(sfd, p->ai_addr, p->ai_addrlen) == -1) {
466 474 close(sfd);
467 475 perror("bind() failed");
468 476 continue;
469 477 }
470 478
471 479 break;
472 480 }
473 481
474 482 if (p == NULL) {
475 483 fprintf(stderr, "server failed to bind()\n");
476 484 return (1);
477 485 }
478 486
479 487 freeaddrinfo(gair);
480 488
481 489 if (listen(sfd, 1024) != 0) {
482 490 perror("listen() failed");
483 491 return (1);
484 492 }
485 493
486 494 fprintf(stdout, "waiting for clients...\n");
487 495
488 496 for (int times = 0; times < 5; times++) {
489 497 struct sockaddr_storage stor;
490 498 socklen_t alen = sizeof (stor);
491 499 struct sockaddr *addr = (struct sockaddr *)&stor;
492 500
493 501 if ((cfd = accept(sfd, addr, &alen)) == -1) {
494 502 perror("accept() failed");
495 503 continue;
496 504 }
497 505
498 506 wlen = 0;
499 507
500 508 do {
501 509 wlen += write(cfd, argv[2] + wlen, slen - wlen);
502 510 } while (wlen < slen);
503 511
504 512 logmsg(addr, wlen);
505 513
506 514 if (close(cfd) == -1) {
507 515 perror("close(cfd) failed");
508 516 }
509 517 }
510 518
511 519 if (close(sfd) == -1) {
512 520 perror("close(sfd) failed");
513 521 }
514 522
515 523 fprintf(stdout, "finished.\n");
516 524
517 525 return (0);
518 526 }
519 527 $ ./server 8080 $'hello\n'
520 528 waiting for clients...
521 529 sent 6 bytes to [::ffff:127.0.0.1]:59059
522 530 sent 6 bytes to [::ffff:127.0.0.1]:47448
523 531 sent 6 bytes to [::ffff:127.0.0.1]:54949
524 532 sent 6 bytes to [::ffff:127.0.0.1]:55186
525 533 sent 6 bytes to [::1]:62256
526 534 finished.
527 535
528 536 DIAGNOSTICS
529 537 A socket operation may fail if:
530 538
531 539 EISCONN A connect() operation was attempted on a socket
532 540 on which a connect() operation had already been
533 541 performed.
534 542
535 543 ETIMEDOUT A connection was dropped due to excessive
536 544 retransmissions.
537 545
538 546 ECONNRESET The remote peer forced the connection to be
539 547 closed (usually because the remote machine has
540 548 lost state information about the connection due
541 549 to a crash).
542 550
543 551 ECONNREFUSED The remote peer actively refused connection
544 552 establishment (usually because no process is
545 553 listening to the port).
546 554
547 555 EADDRINUSE A bind() operation was attempted on a socket with
548 556 a network address/port pair that has already been
549 557 bound to another socket.
550 558
551 559 EADDRNOTAVAIL A bind() operation was attempted on a socket with
552 560 a network address for which no network interface
553 561 exists.
554 562
555 563 EACCES A bind() operation was attempted with a
556 564 "reserved" port number and the effective user ID
557 565 of the process was not the privileged user.
558 566
559 567 ENOBUFS The system ran out of memory for internal data
560 568 structures.
561 569
562 570 SEE ALSO
563 571 svcs(1), ndd(1M), svcadm(1M), ioctl(2), read(2), write(2),
564 572 accept(3SOCKET), bind(3SOCKET), connect(3SOCKET),
565 573 getprotobyname(3SOCKET), getsockopt(3SOCKET), listen(3SOCKET),
566 574 send(3SOCKET), smf(5), inet(7P), inet6(7P), ip(7P), ip6(7P)
567 575
568 576 K. Ramakrishnan, S. Floyd, and D. Black, The Addition of Explicit
569 577 Congestion Notification (ECN) to IP, RFC 3168, September 2001.
570 578
571 579 M. Mathias, J. Mahdavi, S. Ford, and A. Romanow, TCP Selective
572 580 Acknowledgement Options, RFC 2018, October 1996.
573 581
574 582 S. Bellovin, Defending Against Sequence Number Attacks, RFC 1948, May
575 583 1996.
576 584
577 585 D. Borman, B. Braden, V. Jacobson, and R. Scheffenegger, Ed., TCP
578 586 Extensions for High Performance, RFC 7323, September 2014.
579 587
580 588 Jon Postel, Transmission Control Protocol - DARPA Internet Program
581 589 Protocol Specification, RFC 793, Network Information Center, SRI
582 590 International, Menlo Park, CA., September 1981.
583 591
584 592 NOTES
585 593 The tcp service is managed by the service management facility, smf(5),
586 594 under the service identifier svc:/network/initial:default.
587 595
588 596 Administrative actions on this service, such as enabling, disabling, or
589 597 requesting restart, can be performed using svcadm(1M). The service's
590 598 status can be queried using the svcs(1) command.
591 599
592 600 illumos January 7, 2019 illumos
|
↓ open down ↓ |
430 lines elided |
↑ open up ↑ |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX