*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->FreeBSD man pages -> ttcp (4)              



NAME    [Toc]    [Back]

     ttcp -- Transmission Control Protocol Extensions for Transactions

SYNOPSIS    [Toc]    [Back]

     #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);

DESCRIPTION    [Toc]    [Back]

     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 twopacket
 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 recognize
 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 negotiation
 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 automatically degenerate into standard TCP.

TRANSACTION MODEL    [Toc]    [Back]

     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)
	  options and data back to the client.	If not, then the connection
	  degenerates into (almost) the usual case for TCP.  The server then
	  closes its socket.

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

CLIENT SUPPORT    [Toc]    [Back]

     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 following

	   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 destination.)

SERVER SUPPORT    [Toc]    [Back]

     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
     existing 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

MIB VARIABLES    [Toc]    [Back]

     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.

SEE ALSO    [Toc]    [Back]

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

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

HISTORY    [Toc]    [Back]

     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,
     Information Sciences Institute, and ported by Andras Olah at the University
 of Twente.

FreeBSD 5.2.1		       January 18, 1995 		 FreeBSD 5.2.1
[ Back ]
 Similar pages
Name OS Title
tcp FreeBSD Internet Transmission Control Protocol
tcp IRIX Internet Transmission Control Protocol
tcp Tru64 Internet Transmission Control Protocol (TCP)
tcp OpenBSD Internet Transmission Control Protocol
hosts_options FreeBSD host access control language extensions
hosts_options HP-UX host access control language extensions
hosts_options Linux host access control language extensions
hosts_options OpenBSD tcp wrapper host access control language extensions
uuls HP-UX list spooled uucp transactions grouped by transaction
icmp FreeBSD Internet Control Message Protocol
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service