4398 Extra spaces in man pages

          --- 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    8  .TH TCP 7P "Jun 30, 2006"
   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      - If an application does not want to allow another socket  using the
      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
 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  186  SunOS supports \fBTCP\fR Extensions for High Performance (\fIRFC 1323\fR) which
 187  187  includes the window scale and time stamp options, and Protection Against Wrap
 188  188  Around Sequence Numbers (PAWS). SunOS also supports Selective Acknowledgment
 189  189  (SACK) capabilities (RFC 2018) and Explicit Congestion Notification (ECN)
 190  190  mechanism (\fIRFC 3168\fR).
 191  191  .sp
 192  192  .LP
 193  193  Turn on the window scale option in one of the following ways:
 194  194  .RS +4
 195  195  .TP
 196  196  .ie t \(bu
 197  197  .el o
 198  198  An application can set \fBSO_SNDBUF\fR or \fBSO_RCVBUF\fR size in the
 199  199  \fBsetsockopt()\fR option to be larger than 64K. This must be done \fIbefore\fR
 200  200  the program calls \fBlisten()\fR or \fBconnect()\fR, because the window scale
 201  201  option is negotiated when the connection is established. Once the connection
 202  202  has been made, it is too late to increase the send or receive window beyond the
 203  203  default \fBTCP\fR limit of 64K.
 204  204  .RE
 205  205  .RS +4
 206  206  .TP
 207  207  .ie t \(bu
 208  208  .el o
 209  209  For all applications, use \fBndd\fR(1M) to modify the configuration parameter
 210  210  \fBtcp_wscale_always\fR. If \fBtcp_wscale_always\fR is set to \fB1\fR, the
 211  211  window scale option will always be set when connecting to a remote system. If
 212  212  \fBtcp_wscale_always\fR is \fB0,\fR the window scale option will be set only if
 213  213  the user has requested a send or receive window larger than 64K. The default
 214  214  value of \fBtcp_wscale_always\fR is \fB1\fR.
 215  215  .RE
 216  216  .RS +4
 217  217  .TP
 218  218  .ie t \(bu
 219  219  .el o
 220  220  Regardless of the value of \fBtcp_wscale_always\fR, the window scale option
 221  221  will always be included in a connect acknowledgement if the connecting system
 222  222  has used the option.
 223  223  .RE
 224  224  .sp
 225  225  .LP
 226  226  Turn on \fBSACK\fR capabilities in the following way:
 227  227  .RS +4
 228  228  .TP
 229  229  .ie t \(bu
 230  230  .el o
 231  231  Use \fBndd\fR to modify the configuration parameter \fBtcp_sack_permitted\fR.
 232  232  If \fBtcp_sack_permitted\fR is set to \fB0\fR, \fBTCP\fR will not accept
 233  233  \fBSACK\fR or send out \fBSACK\fR information. If \fBtcp_sack_permitted\fR is
 234  234  set to \fB1\fR, \fBTCP\fR will not initiate a connection with \fBSACK\fR
 235  235  permitted option in the \fBSYN\fR segment, but will respond with \fBSACK\fR
 236  236  permitted option in the \fBSYN|ACK\fR segment if an incoming connection request
 237  237  has the \fBSACK \fR permitted option. This means that \fBTCP\fR will only
 238  238  accept \fBSACK\fR information if the other side of the connection also accepts
 239  239  \fBSACK\fR information. If \fBtcp_sack_permitted\fR is set to \fB2\fR, it will
 240  240  both initiate and accept connections with \fBSACK\fR information. The default
 241  241  for \fBtcp_sack_permitted\fR is \fB2\fR (active enabled).
 242  242  .RE
 243  243  .sp
 244  244  .LP
 245  245  Turn on \fBTCP ECN\fR mechanism in the following way:
 246  246  .RS +4
 247  247  .TP
 248  248  .ie t \(bu
 249  249  .el o
 250  250  Use \fBndd\fR to modify the configuration parameter \fBtcp_ecn_permitted\fR. If
 251  251  \fBtcp_ecn_permitted\fR is set to \fB0\fR, \fBTCP\fR will not negotiate with a
 252  252  peer that supports \fBECN\fR mechanism. If \fBtcp_ecn_permitted\fR is set to
 253  253  \fB1\fR when initiating a connection, TCP will not tell a peer that it supports
 254  254  ECN mechanism. However, it will tell a peer that it supports \fBECN\fR
 255  255  mechanism when accepting a new incoming connection request if the peer
 256  256  indicates that it supports \fBECN\fR mechanism in the SYN segment. If
 257  257  tcp_ecn_permitted is set to 2, in addition to negotiating with a peer on ECN
 258  258  mechanism when accepting connections, TCP will indicate in the outgoing SYN
 259  259  segment that it supports \fBECN\fR mechanism when \fBTCP\fR makes active
 260  260  outgoing connections. The default for \fBtcp_ecn_permitted\fR is 1.
 261  261  .RE
 262  262  .sp
 263  263  .LP
 264  264  Turn on the time stamp option in the following way:
 265  265  .RS +4
 266  266  .TP
 267  267  .ie t \(bu
 268  268  .el o
 269  269  Use \fBndd\fR to modify the configuration parameter \fBtcp_tstamp_always\fR. If
 270  270  \fBtcp_tstamp_always\fR is \fB1\fR, the time stamp option will always be set
 271  271  when connecting to a remote machine. If \fBtcp_tstamp_always\fR is \fB0\fR, the
 272  272  timestamp option will not be set when connecting to a remote system. The
 273  273  default for \fBtcp_tstamp_always\fR is \fB0\fR.
 274  274  .RE
 275  275  .RS +4
 276  276  .TP
 277  277  .ie t \(bu
 278  278  .el o
 279  279  Regardless of the value of \fBtcp_tstamp_always\fR, the time stamp option will
 280  280  always be included in a connect acknowledgement (and all succeeding packets) if
 281  281  the connecting system has used the time stamp option.
 282  282  .RE
 283  283  .sp
 284  284  .LP
 285  285  Use the following procedure to turn on the time stamp option only when the
 286  286  window scale option is in effect:
 287  287  .RS +4
 288  288  .TP
 289  289  .ie t \(bu
 290  290  .el o
 291  291  Use \fBndd\fR to modify the configuration parameter \fBtcp_tstamp_if_wscale\fR.
 292  292  Setting \fBtcp_tstamp_if_wscale\fR to \fB1\fR will cause the time stamp option
 293  293  to be set when connecting to a remote system, if the window scale option has
 294  294  been set. If \fBtcp_tstamp_if_wscale\fR is \fB0\fR, the time stamp option will
 295  295  not be set when connecting to a remote system. The default for
 296  296  \fBtcp_tstamp_if_wscale\fR is \fB1\fR.
 297  297  .RE
 298  298  .sp
 299  299  .LP
 300  300  Protection Against Wrap Around Sequence Numbers (PAWS) is always used when the
 301  301  time stamp option is set.
 302  302  .sp
 303  303  .LP
 304  304  SunOS also supports multiple methods of generating initial sequence numbers.
 305  305  One of these methods is the improved technique suggested in \fBRFC\fR 1948. We
 306  306  \fBHIGHLY\fR recommend that you set sequence number generation parameters as
 307  307  close to boot time as possible. This prevents sequence number problems on
 308  308  connections that use the same connection-ID as ones that used a different
 309  309  sequence number generation. The \fBsvc:/network/initial:default\fR service
 310  310  configures the initial sequence number generation.  The service reads the value
 311  311  contained in the configuration file \fB/etc/default/inetinit\fR to determine
 312  312  which method to use.
 313  313  .sp
 314  314  .LP
 315  315  The \fB/etc/default/inetinit\fR file is an unstable interface, and may change
 316  316  in future releases.
 317  317  .sp
 318  318  .LP
 319  319  \fBTCP\fR may be configured to report some information on connections that
 320  320  terminate by means of an \fBRST\fR packet. By default, no logging is done. If
 321  321  the \fBndd\fR(1M) parameter \fItcp_trace\fR is set to 1, then trace data is
 322  322  collected for all new connections established after that time.
 323  323  .sp
 324  324  .LP
 325  325  The trace data consists of the \fBTCP\fR headers and \fBIP\fR source and
 326  326  destination addresses of the last few packets sent in each direction before RST
 327  327  occurred. Those packets are logged in a series of \fBstrlog\fR(9F) calls. This
 328  328  trace facility has a very low overhead, and so is superior to such utilities as
 329  329  \fBsnoop\fR(1M) for non-intrusive debugging for connections terminating by
 330  330  means of an \fBRST\fR.
 331  331  .sp
 332  332  .LP
 333  333  SunOS supports the keep-alive mechanism described in \fIRFC 1122\fR. It is
 334  334  enabled using the socket option SO_KEEPALIVE. When enabled, the first
 335  335  keep-alive probe is sent out after a TCP is idle for two hours If the peer does
 336  336  not respond to the probe within eight minutes, the TCP connection is aborted.
 337  337  You can alter the interval for sending out the first probe using the socket
 338  338  option TCP_KEEPALIVE_THRESHOLD. The option value is an unsigned integer in
 339  339  milliseconds. The system default is controlled by the TCP ndd parameter
 340  340  tcp_keepalive_interval. The minimum value is ten seconds. The maximum is ten
 341  341  days, while the default is two hours. If you receive no response to the probe,
 342  342  you can use the TCP_KEEPALIVE_ABORT_THRESHOLD socket option to change the time
 343  343  threshold for aborting a TCP connection. The option value is an unsigned
 344  344  integer in milliseconds. The value zero indicates that TCP should never time
 345  345  out and abort the connection when probing. The system default is controlled by
 346  346  the TCP ndd parameter tcp_keepalive_abort_interval. The default is eight
 347  347  minutes.
 348  348  .sp
 349  349  .LP
 350  350  socket options TCP_KEEPIDLE, TCP_KEEPCNT and TCP_KEEPINTVL are also supported
 351  351  for compatibility with other Unix Flavors. TCP_KEEPIDLE option specifies the
 352  352  interval in seconds for sending out the first keep-alive probe. TCP_KEEPCNT
 353  353  specifies the number of keep-alive probes to be sent before aborting the
 354  354  connection in the event of no response from peer. TCP_KEEPINTVL specifies the
 355  355  interval in seconds between successive keep-alive probes.
 356  356  .SH SEE ALSO
 357  357  .sp
 358  358  .LP
 359  359  \fBsvcs\fR(1), \fBndd\fR(1M), \fBioctl\fR(2), \fBread\fR(2), \fBsvcadm\fR(1M),
 360  360  \fBwrite\fR(2), \fBaccept\fR(3SOCKET), \fBbind\fR(3SOCKET),
 361  361  \fBconnect\fR(3SOCKET), \fBgetprotobyname\fR(3SOCKET),
 362  362  \fBgetsockopt\fR(3SOCKET), \fBlisten\fR(3SOCKET), \fBsend\fR(3SOCKET),
 363  363  \fBsmf\fR(5), \fBinet\fR(7P), \fBinet6\fR(7P), \fBip\fR(7P), \fBip6\fR(7P)
 364  364  .sp
 365  365  .LP
 366  366  Ramakrishnan, K., Floyd, S., Black, D., RFC 3168, \fIThe Addition of Explicit
 367  367  Congestion Notification (ECN) to IP\fR, September 2001.
 368  368  .sp
 369  369  .LP
 370  370  Mathias, M. and Hahdavi, J. Pittsburgh Supercomputing Center; Ford, S. Lawrence
 371  371  Berkeley National Laboratory; Romanow, A. Sun Microsystems, Inc. \fIRFC 2018,
 372  372  TCP Selective Acknowledgement Options\fR, October 1996.
 373  373  .sp
 374  374  .LP
 375  375  Bellovin, S., \fIRFC 1948, Defending Against Sequence Number Attacks\fR, May
 376  376  1996.
 377  377  .sp
 378  378  .LP
 379  379  Jacobson, V., Braden, R., and Borman, D., \fIRFC 1323, TCP Extensions for High
 380  380  Performance\fR, May 1992.
 381  381  .sp
 382  382  .LP
 383  383  Postel, Jon, \fIRFC 793, Transmission Control Protocol - DARPA Internet Program
 384  384  Protocol Specification\fR, Network Information Center, SRI International, Menlo
 385  385  Park, CA., September 1981.
 386  386  .SH DIAGNOSTICS
 387  387  .sp
 388  388  .LP
 389  389  A socket operation may fail if:
 390  390  .sp
 391  391  .ne 2
 392  392  .na
 393  393  \fB\fBEISCONN\fR\fR
 394  394  .ad
 395  395  .RS 17n
 396  396  A \fBconnect()\fR operation was attempted on a socket on which a
 397  397  \fBconnect()\fR operation had already been performed.
 398  398  .RE
 399  399  
 400  400  .sp
 401  401  .ne 2
 402  402  .na
 403  403  \fB\fBETIMEDOUT\fR\fR
 404  404  .ad
 405  405  .RS 17n
 406  406  A connection was dropped due to excessive retransmissions.
 407  407  .RE
 408  408  
 409  409  .sp
 410  410  .ne 2
 411  411  .na
 412  412  \fB\fBECONNRESET\fR\fR
 413  413  .ad
 414  414  .RS 17n
 415  415  The remote peer forced the connection to be closed (usually because the remote
 416  416  machine has lost state information about the connection due to a crash).
 417  417  .RE
 418  418  
 419  419  .sp
 420  420  .ne 2
 421  421  .na
 422  422  \fB\fBECONNREFUSED\fR\fR
 423  423  .ad
 424  424  .RS 17n
 425  425  The remote peer actively refused connection establishment (usually because no
 426  426  process is listening to the port).
 427  427  .RE
 428  428  
 429  429  .sp
 430  430  .ne 2
 431  431  .na
 432  432  \fB\fBEADDRINUSE\fR\fR
 433  433  .ad
 434  434  .RS 17n
 435  435  A \fBbind()\fR operation was attempted on a socket with a network address/port
 436  436  pair that has already been bound to another socket.
 437  437  .RE
 438  438  
 439  439  .sp
 440  440  .ne 2
 441  441  .na
 442  442  \fB\fBEADDRNOTAVAIL\fR\fR
 443  443  .ad
 444  444  .RS 17n
 445  445  A \fBbind()\fR operation was attempted on a socket with a network address for
 446  446  which no network interface exists.
 447  447  .RE
 448  448  
 449  449  .sp
 450  450  .ne 2
 451  451  .na
 452  452  \fB\fBEACCES\fR\fR
 453  453  .ad
 454  454  .RS 17n
 455  455  A \fBbind()\fR operation was attempted with a "reserved" port number and the
 456  456  effective user \fBID\fR of the process was not the privileged user.
 457  457  .RE
 458  458  
 459  459  .sp
 460  460  .ne 2
 461  461  .na
 462  462  \fB\fBENOBUFS\fR\fR
 463  463  .ad
 464  464  .RS 17n
 465  465  The system ran out of memory for internal data structures.
 466  466  .RE
 467  467  
 468  468  .SH NOTES
 469  469  .sp
 470  470  .LP
 471  471  The \fBtcp\fR service is managed by the service management facility,
 472  472  \fBsmf\fR(5), under the service identifier:
 473  473  .sp
 474  474  .in +2
 475  475  .nf
 476  476  svc:/network/initial:default
 477  477  .fi
 478  478  .in -2
 479  479  .sp
 480  480  
 481  481  .sp
 482  482  .LP
 483  483  Administrative actions on this service, such as enabling, disabling, or
 484  484  requesting restart, can be performed using \fBsvcadm\fR(1M). The service's
 485  485  status can be queried using the \fBsvcs\fR(1) command.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX