Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
TTCP(4)			 BSD Kernel Interfaces Manual		       TTCP(4)

     ttcp -- Transmission Control Protocol Extensions for Transactions

     #include <sys/types.h>
     #include <sys/socket.h>
     #include <netinet/in.h>
     #include <netinet/tcp.h>

     setsockopt(sock, IPPROTO_TCP, TCP_NOPUSH, _One, sizeof One);

     sendto(sock, msg, len, MSG_EOF, _sin, sizeof sin);

     sendto(sock, msg, len, MSG_EOF, 0,	0);

     T/TCP refers to a set of extensions to the	TCP protocol (see tcp(4))
     which permit hosts	to reliably exchange a small amount of data in a two-
     packet exchange, thus eliminating the extra round-trip delays inherent in
     a standard	TCP connection.	 The socket interface includes modifications
     to	support	T/TCP, detailed	here for the specific case, and	in the
     socket(2) and send(2) manual pages	for the	protocol-independent support.
     T/TCP is defined in RFC 1644.

     The T/TCP extensions work by including certain options in all segments of
     a particular connection, which enable the implementation to avoid the
     three-way handshake for all but the first connection between a pair of
     hosts.  These same	options	also make it possible to more reliably recog-
     nize old, duplicate packets, which	in turn	reduces	the amount of time the
     TCP protocol must maintain	state after a connection closes.  The
     "net.inet.tcp.rfc1644" MIB	variable can be	used to	disable	T/TCP negotia-
     tion at run time; however,	the protocol has been designed to ensure that
     attempts by non-T/TCP systems to communicate with T/TCP-enhanced ones au-
     tomatically degenerate into standard TCP.

     The expected model	of a "transaction" as used by T/TCP is a fairly	simple

     1.	  A client program generates a request to be sent to the server, which
	  is small enough to fit in a single TCP segment, and sends a SYN PUSH
	  FIN segment with options and data to the server.

     2.	  The server program accepts the request in the	same manner as for
	  regular TCP connections, interprets it, and generates	a reply	which
	  may be small enough to fit in	a single segment.  If it is, the reply
	  is sent in a single SYN PUSH FIN ACK segment with (different)	op-
	  tions	and data back to the client.  If not, then the connection de-
	  generates into (almost) the usual case for TCP.  The server then
	  closes its socket.

     3.	  The client reads the reply and closes	its socket.

     Support on	the client side	is provided by extending the semantics of the
     sendto(2) and sendmsg(2) system calls to understand the notion of
     "implied connect" and "send and shutdown".	 To send the request in	a
     transaction, the sendto(2)	system call is typically used, as in the fol-
     lowing example:

	   char	request[REQ_LEN];
	   struct sockaddr_in sin;
	   int sock, req_len;

	   sock	= socket(PF_INET, SOCK_STREAM, 0);

	   /* prepare request[]	and sin	*/

	   err = sendto(sock, request, req_len,	MSG_EOF,
		   (struct sockaddr *)&sin, sin.sin_len);

	   /* do something if error */

	   req_len = read(sock,	request, sizeof	request);

	   /* do something with	the reply */

     Note that,	after the call to sendto(), the	socket is now in the same
     state as if the connect(2)	and shutdown(2)	system calls had been used.
     That is to	say, the only reasonable operations to perform on this socket
     are read(2) and close(2).	(As the	client's TCP sender is already shut
     down, it is not possible to connect(2) this socket	to another destina-

     There are two different options available for servers using T/TCP:

     1.	  Set the TCP_NOPUSH socket option, and	use normal write(2) calls when
	  formulating the response.

     2.	  Use sendto(2)	with the MSG_EOF flag, as in the client, but with the
	  destination unspecified.

     The first option is generally the appropriate choice when converting ex-
     isting servers to use T/TCP extensions; simply add	a call to
     setsockopt(sock, IPPROTO_TCP, TCP_NOPUSH, _One, sizeof One) (where	One is
     an	integer	variable with a	non-zero value).  The server socket must be
     closed before any data is sent (unless the	socket buffers fill up).

     The second	option is preferable for new servers, and is sometimes easy
     enough to retrofit	into older servers.  In	this case, where the reply
     phase would ordinarily have included a call to write(), one substitutes:

	   sendto(sock,	buf, len, MSG_EOF, (struct sockaddr *)0, 0)

     In	this case, the reply is	sent immediately, but as in the	client case,
     the socket	is no longer useful for	anything and should be immediately

     The T/TCP extensions require the "net.inet.tcp.rfc1644" MIB variable to
     be	true in	order for the appropriate TCP options to be sent.  See tcp(4)
     for more information.

     send(2), setsockopt(2), inet(4), tcp(4)

     R.	Braden,	T/TCP -	TCP Extensions for Transactions, RFC 1644.

     Support for T/TCP first appeared in FreeBSD 2.1, based on code written by
     Bob Braden	and Liming Wei at the University of Southern California, In-
     formation Sciences	Institute, and ported by Andras	Olah at	the University
     of	Twente.

BSD			       January 18, 1995				   BSD


Want to link to this manual page? Use this URL:

home | help