Path: utzoo!attcan!uunet!nih-csl!lhc!ncifcrf!haven!udel!wuarchive!emory!gatech!mcnc!decwrl!ucbvax!VENERA.ISI.EDU!braden
From: braden@VENERA.ISI.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Datagram ??? Protocols
Message-ID: <9010251653.AA05374@braden.isi.edu>
Date: 25 Oct 90 16:53:42 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 25


	Anyway, one other goal of some people in search of something other than
	TCP is the reduction in the number of network messages that need to be
	exchanged for short-lived connections (which often occur when you're
	doing RPC), in particular eliminating some of the connection setup and
	tear-down messages.  E.g., for the purposes of RPC, it sure would have
	been nice if I could do something like send data (i.e., the remote call's
	input parameters) in a SYN.  (I've never seen an implementation that
	allows this; I can't point to the place in the TCP spec that disallows
	it, but I imagine it is disallowed.) 
	
Nat,

It certainly is NOT disallowed, and all of the early research TCP's
tried to support it.  A favorite test in "bake-offs" was to send a
"Kamakazii packet", with SYN, data, and FIN all in one segment.  Not
all TCP's survived the test, but some did...  However, sending data with
the original SYN (sic) is not a big win because a full 3-way handshake
is necessary before the data can be passed to the receiving
application.  Other protocols, e.g., delta-T and VMTP, use a timer-based
mechanism to avoid 3-way handshakes; this leads to what is commonly
called a "transaction transport protocol" (see RFC-955).

Bob Braden