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$
  29 .\"
  30 .Dd January 18, 1995
  31 .Dt TTCP 4
  32 .Os FreeBSD 2.1
  33 .Sh NAME
  34 .Nm ttcp
  35 .Nd Transmission Control Protocol Extensions for Transactions
  36 .Sh
  37 .Fd #include <sys/types.h>
  38 .Fd #include <sys/socket.h>
  39 .Fd #include <netinet/in.h>
  40 .Fd #include <netinet/tcp.h>
  41 .Ft int
  42 .Fn setsockopt sock IPPROTO_TCP TCP_NOPUSH &One "sizeof One"
  43 .br
  44 .Ft ssize_t
  45 .Fn sendto sock msg len MSG_EOF &sin "sizeof sin"
  46 .br
  47 .Ft ssize_t
  48 .Fn sendto sock msg len MSG_EOF 0 0
  49 .Sh DESCRIPTION
  50 .Tn T/TCP
  51 refers to a set of extensions to the
  52 .Tn TCP
  53 protocol (see
  54 .Xr tcp 4 )
  55 which permit hosts to reliably exchange a small amount of data in a
  56 two-packet exchange, thus eliminating the extra round-trip delays
  57 inherent in a standard
  58 .Tn TCP
  59 connection.  The socket interface includes modifications to support
  60 .Tn T/TCP ,
  61 detailed here for the specific case, and in the
  62 .Xr socket 2
  63 and
  64 .Xr send 2
  65 manual pages for the protocol-independent support.
  66 .Tn T/TCP
  67 is defined in RFC 1644.
  68 .Pp
  69 The
  70 .Tn T/TCP
  71 extensions work by including certain options in all segments of a
  72 particular connection, which enable the implementation to avoid the
  73 three-way handshake for all but the first connection between a pair of
  74 hosts.  These same options also make it possible to more reliably
  75 recognize old, duplicate packets, which in turn reduces the amount of
  76 time the
  77 .Tn TCP
  78 protocol must maintain state after a connection closes.  The
  79 .Dq Li net.inet.tcp.rfc1644
  80 MIB variable can be used to disable
  81 .Tn T/TCP
  82 negotiation at run time; however, the protocol has been designed to
  83 ensure that attempts by non-T/TCP
  84 systems to communicate with T/TCP-enhanced
  85 ones automatically degenerate into standard
  86 .Tn TCP .
  87 .Sh TRANSACTION MODEL
  88 The expected model of a
  89 .Dq transaction
  90 as used by
  91 .Tn T/TCP
  92 is a fairly simple one:
  93 .Bl -enum
  94 .It
  95 A client program generates a request to be sent to the server, which
  96 is small enough to fit in a single
  97 .Tn TCP
  98 segment, and sends a SYN PUSH FIN segment with options and data to the
  99 server.
 100 .It
 101 The server program accepts the request in the same manner as for
 102 regular
 103 .Tn TCP
 104 connections, interprets it, and generates a reply which may be small
 105 enough to fit in a single segment.  If it is, the reply is sent in a
 106 single SYN PUSH FIN ACK segment with (different) options and data back
 107 to the client.  If not, then the connection degenerates into (almost)
 108 the usual case for
 109 .Tn TCP .
 110 The server then closes its socket.
 111 .It
 112 The client reads the reply and closes its socket.
 113 .El
 114 .Sh CLIENT SUPPORT
 115 Support on the client side is provided by extending the semantics of
 116 the
 117 .Xr sendto 2
 118 and
 119 .Xr sendmsg 2
 120 system calls to understand the notion of
 121 .Dq implied connect
 122 and
 123 .Dq send and shutdown.
 124 To send the request in a transaction, the
 125 .Xr sendto 2
 126 system call is typically used, as in the following example:
 127 .Bd -literal -offset indent
 128 char request[REQ_LEN];
 129 struct sockaddr_in sin;
 130 int sock, req_len;
 131
 132 sock = socket(PF_INET, SOCK_STREAM, 0);
 133
 134 /* prepare request[] and sin */
 135
 136 err = sendto(sock, request, req_len, MSG_EOF,
 137         (struct sockaddr *)&sin, sin.sin_len);
 138
 139 /* do something if error */
 140
 141 req_len = read(sock, request, sizeof request);
 142 close(sock);
 143
 144 /* do something with the reply */
 145
 146 .Ed
 147 .Pp
 148 Note that, after the
 149 call to
 150 .Fn sendto ,
 151 the socket is now in the same state as if the
 152 .Xr connect 2
 153 and
 154 .Xr shutdown 2
 155 system calls had been used.  That is to say, the only reasonable
 156 operations to perform on this socket are
 157 .Xr read 2
 158 and
 159 .Xr close 2 .
 160 (Because the client's
 161 .Tn TCP
 162 sender is already shut down, it is not possible to
 163 .Xr connect 2
 164 this socket to another destination.)
 165 .Sh SERVER SUPPORT
 166 There are two different options available for servers using
 167 .Tn T/TCP :
 168 .Bl -enum
 169 .It
 170 Set the
 171 .Dv TCP_NOPUSH
 172 socket option, and use normal
 173 .Xr write 2
 174 calls when formulating the response.
 175 .It
 176 Use
 177 .Xr sendto 2
 178 with the
 179 .Dv MSG_EOF
 180 flag, as in the client, but with the destination unspecified.
 181 .El
 182 .Pp
 183 The first option is generally the appropriate choice when converting
 184 existing servers to use
 185 .Tn T/TCP
 186 extensions; simply add a call to
 187 .Fn setsockopt sock IPPROTO_TCP TCP_NOPUSH &One "sizeof One"
 188 (where
 189 .Va One
 190 is an integer variable with a non-zero value).  The server socket must
 191 be closed before any data is sent (unless the socket buffers fill up).
 192 .Pp
 193 The second option is preferable for new servers, and is sometimes easy
 194 enough to retrofit into older servers.  In this case, where the reply
 195 phase would ordinarily have included a call to
 196 .Fn write ,
 197 one substitutes:
 198 .Pp
 199 .Dl "sendto(sock, buf, len, MSG_EOF, (struct sockaddr *)0, 0)"
 200 .Pp
 201 In this case, the reply is sent immediately, but as in the client
 202 case, the socket is no longer useful for anything and should be
 203 immediately closed.
 204 .Sh MIB VARIABLES
 205 The
 206 .Tn T/TCP
 207 extensions require the
 208 .Dq Li net.inet.tcp.rfc1644
 209 MIB variable to be true in order for the appropriate
 210 .Tn TCP
 211 options to be sent.  See
 212 .Xr tcp 4
 213 for more information.
 214 .Sh SEE ALSO
 215 .Xr send 2 ,
 216 .Xr setsockopt 2 ,
 217 .Xr inet 4 ,
 218 .Xr tcp 4
 219 .Rs
 220 .%A R. Braden
 221 .%T "T/TCP \- TCP Extensions for Transactions"
 222 .%O RFC 1644
 223 .Re
 224 .Sh HISTORY
 225 Support for
 226 .Tn T/TCP
 227 first appeared in
 228 .Fx 2.1 ,
 229 based on code written by Bob Braden and Liming Wei at the
 230 University of Southern California, Information Sciences Institute, and
 231 ported by Andras Olah at the University of Twente.