share/doc/smm/18.net/d.t

   1 .\" Copyright (c) 1983, 1986, 1993
   2 .\"     The Regents of the University of California.  All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. All advertising materials mentioning features or use of this software
  13 .\"    must display the following acknowledgement:
  14 .\"     This product includes software developed by the University of
  15 .\"     California, Berkeley and its contributors.
  16 .\" 4. Neither the name of the University nor the names of its contributors
  17 .\"    may be used to endorse or promote products derived from this software
  18 .\"    without specific prior written permission.
  19 .\"
  20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30 .\" SUCH DAMAGE.
  31 .\"
  32 .\"     @(#)d.t 8.1 (Berkeley) 6/8/93
  33 .\"
  34 .nr H2 1
  35 .\".ds RH "Out of band data
  36 .br
  37 .ne 2i
  38 .NH
  39 \s+2Out of band data\s0
  40 .PP
  41 Out of band data is a facility peculiar to the stream socket
  42 abstraction defined.  Little agreement appears to exist as
  43 to what its semantics should be.  TCP defines the notion of
  44 ``urgent data'' as in-line, while the NBS protocols [Burruss81]
  45 and numerous others provide a fully independent logical
  46 transmission channel along which out of band data is to be
  47 sent.
  48 In addition, the amount of the data which may be sent as an out
  49 of band message varies from protocol to protocol; everything
  50 from 1 bit to 16 bytes or more.
  51 .PP
  52 A stream socket's notion of out of band data has been defined
  53 as the lowest reasonable common denominator (at least reasonable
  54 in our minds);
  55 clearly this is subject to debate.  Out of band data is expected
  56 to be transmitted out of the normal sequencing and flow control
  57 constraints of the data stream.  A minimum of 1 byte of out of
  58 band data and one outstanding out of band message are expected to
  59 be supported by the protocol supporting a stream socket.
  60 It is a protocol's prerogative to support larger-sized messages, or
  61 more than one outstanding out of band message at a time.
  62 .PP
  63 Out of band data is maintained by the protocol and is usually not
  64 stored in the socket's receive queue.
  65 A socket-level option, SO_OOBINLINE,
  66 is provided to force out-of-band data to be placed in the normal
  67 receive queue when urgent data is received;
  68 this sometimes amelioriates problems due to loss of data
  69 when multiple out-of-band
  70 segments are received before the first has been passed to the user.
  71 The PRU_SENDOOB and PRU_RCVOOB
  72 requests to the \fIpr_usrreq\fP routine are used in sending and
  73 receiving data.