share/man/man4/ttcp.4

   1 .\" Copyright 1994, 1995 Massachusetts Institute of Technology
   2 .\"
   3 .\" Permission to use, copy, modify, and distribute this software and
   4 .\" its documentation for any purpose and without fee is hereby
   5 .\" granted, provided that both the above copyright notice and this
   6 .\" permission notice appear in all copies, that both the above
   7 .\" copyright notice and this permission notice appear in all
   8 .\" supporting documentation, and that the name of M.I.T. not be used
   9 .\" in advertising or publicity pertaining to distribution of the
  10 .\" software without specific, written prior permission.  M.I.T. makes
  11 .\" no representations about the suitability of this software for any
  12 .\" purpose.  It is provided "as is" without express or implied
  13 .\" warranty.
  14 .\"
  15 .\" THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''.  M.I.T. DISCLAIMS
  16 .\" ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE,
  17 .\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
  18 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT
  19 .\" SHALL M.I.T. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  20 .\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  21 .\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
  22 .\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  23 .\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  24 .\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
  25 .\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  26 .\" SUCH DAMAGE.
  27 .\"
  28 .\" $FreeBSD: src/share/man/man4/ttcp.4,v 1.8.2.6 2001/12/17 11:30:12 ru Exp $
  29 .\"
  30 .Dd January 18, 1995
  31 .Dt TTCP 4
  32 .Os
  33 .Sh NAME
  34 .Nm ttcp
  35 .Nd Transmission Control Protocol Extensions for Transactions
  36 .Sh SYNOPSIS
  37 .In sys/types.h
  38 .In sys/socket.h
  39 .In netinet/in.h
  40 .In netinet/tcp.h
  41 .Ft int
  42 .Fn setsockopt sock IPPROTO_TCP TCP_NOPUSH &One "sizeof One"
  43 .Ft ssize_t
  44 .Fn sendto sock msg len MSG_EOF &sin "sizeof sin"
  45 .Ft ssize_t
  46 .Fn sendto sock msg len MSG_EOF 0 0
  47 .Sh DESCRIPTION
  48 .Tn T/TCP
  49 refers to a set of extensions to the
  50 .Tn TCP
  51 protocol (see
  52 .Xr tcp 4 )
  53 which permit hosts to reliably exchange a small amount of data in a
  54 two-packet exchange, thus eliminating the extra round-trip delays
  55 inherent in a standard
  56 .Tn TCP
  57 connection.  The socket interface includes modifications to support
  58 .Tn T/TCP ,
  59 detailed here for the specific case, and in the
  60 .Xr socket 2
  61 and
  62 .Xr send 2
  63 manual pages for the protocol-independent support.
  64 .Tn T/TCP
  65 is defined in RFC 1644.
  66 .Pp
  67 The
  68 .Tn T/TCP
  69 extensions work by including certain options in all segments of a
  70 particular connection, which enable the implementation to avoid the
  71 three-way handshake for all but the first connection between a pair of
  72 hosts.  These same options also make it possible to more reliably
  73 recognize old, duplicate packets, which in turn reduces the amount of
  74 time the
  75 .Tn TCP
  76 protocol must maintain state after a connection closes.  The
  77 .Dq Li net.inet.tcp.rfc1644
  78 MIB variable can be used to disable
  79 .Tn T/TCP
  80 negotiation at run time; however, the protocol has been designed to
  81 ensure that attempts by non-T/TCP
  82 systems to communicate with T/TCP-enhanced
  83 ones automatically degenerate into standard
  84 .Tn TCP .
  85 .Sh TRANSACTION MODEL
  86 The expected model of a
  87 .Dq transaction
  88 as used by
  89 .Tn T/TCP
  90 is a fairly simple one:
  91 .Bl -enum
  92 .It
  93 A client program generates a request to be sent to the server, which
  94 is small enough to fit in a single
  95 .Tn TCP
  96 segment, and sends a SYN PUSH FIN segment with options and data to the
  97 server.
  98 .It
  99 The server program accepts the request in the same manner as for
 100 regular
 101 .Tn TCP
 102 connections, interprets it, and generates a reply which may be small
 103 enough to fit in a single segment.  If it is, the reply is sent in a
 104 single SYN PUSH FIN ACK segment with (different) options and data back
 105 to the client.  If not, then the connection degenerates into (almost)
 106 the usual case for
 107 .Tn TCP .
 108 The server then closes its socket.
 109 .It
 110 The client reads the reply and closes its socket.
 111 .El
 112 .Sh CLIENT SUPPORT
 113 Support on the client side is provided by extending the semantics of
 114 the
 115 .Xr sendto 2
 116 and
 117 .Xr sendmsg 2
 118 system calls to understand the notion of
 119 .Dq implied connect
 120 and
 121 .Dq send and shutdown .
 122 To send the request in a transaction, the
 123 .Xr sendto 2
 124 system call is typically used, as in the following example:
 125 .Bd -literal -offset indent
 126 char request[REQ_LEN];
 127 struct sockaddr_in sin;
 128 int sock, req_len;
 129
 130 sock = socket(PF_INET, SOCK_STREAM, 0);
 131
 132 /* prepare request[] and sin */
 133
 134 err = sendto(sock, request, req_len, MSG_EOF,
 135         (struct sockaddr *)&sin, sin.sin_len);
 136
 137 /* do something if error */
 138
 139 req_len = read(sock, request, sizeof request);
 140 close(sock);
 141
 142 /* do something with the reply */
 143
 144 .Ed
 145 .Pp
 146 Note that, after the
 147 call to
 148 .Fn sendto ,
 149 the socket is now in the same state as if the
 150 .Xr connect 2
 151 and
 152 .Xr shutdown 2
 153 system calls had been used.  That is to say, the only reasonable
 154 operations to perform on this socket are
 155 .Xr read 2
 156 and
 157 .Xr close 2 .
 158 (Because the client's
 159 .Tn TCP
 160 sender is already shut down, it is not possible to
 161 .Xr connect 2
 162 this socket to another destination.)
 163 .Sh SERVER SUPPORT
 164 There are two different options available for servers using
 165 .Tn T/TCP :
 166 .Bl -enum
 167 .It
 168 Set the
 169 .Dv TCP_NOPUSH
 170 socket option, and use normal
 171 .Xr write 2
 172 calls when formulating the response.
 173 .It
 174 Use
 175 .Xr sendto 2
 176 with the
 177 .Dv MSG_EOF
 178 flag, as in the client, but with the destination unspecified.
 179 .El
 180 .Pp
 181 The first option is generally the appropriate choice when converting
 182 existing servers to use
 183 .Tn T/TCP
 184 extensions; simply add a call to
 185 .Fn setsockopt sock IPPROTO_TCP TCP_NOPUSH &One "sizeof One"
 186 (where
 187 .Va One
 188 is an integer variable with a non-zero value).  The server socket must
 189 be closed before any data is sent (unless the socket buffers fill up).
 190 .Pp
 191 The second option is preferable for new servers, and is sometimes easy
 192 enough to retrofit into older servers.  In this case, where the reply
 193 phase would ordinarily have included a call to
 194 .Fn write ,
 195 one substitutes:
 196 .Pp
 197 .Dl "sendto(sock, buf, len, MSG_EOF, (struct sockaddr *)0, 0)"
 198 .Pp
 199 In this case, the reply is sent immediately, but as in the client
 200 case, the socket is no longer useful for anything and should be
 201 immediately closed.
 202 .Sh MIB VARIABLES
 203 The
 204 .Tn T/TCP
 205 extensions require the
 206 .Dq Li net.inet.tcp.rfc1644
 207 MIB variable to be true in order for the appropriate
 208 .Tn TCP
 209 options to be sent.  See
 210 .Xr tcp 4
 211 for more information.
 212 .Sh SEE ALSO
 213 .Xr send 2 ,
 214 .Xr setsockopt 2 ,
 215 .Xr inet 4 ,
 216 .Xr tcp 4
 217 .Rs
 218 .%A R. Braden
 219 .%T "T/TCP \- TCP Extensions for Transactions"
 220 .%O RFC 1644
 221 .Re
 222 .Sh HISTORY
 223 Support for
 224 .Tn T/TCP
 225 first appeared in
 226 .Fx 2.1 ,
 227 based on code written by Bob Braden and Liming Wei at the
 228 University of Southern California, Information Sciences Institute, and
 229 ported by Andras Olah at the University of Twente.