From owner-freebsd-net@FreeBSD.ORG Mon Sep 13 10:41:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF6D4106564A for ; Mon, 13 Sep 2010 10:41:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 381388FC1A for ; Mon, 13 Sep 2010 10:41:03 +0000 (UTC) Received: (qmail 49160 invoked from network); 13 Sep 2010 10:36:15 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Sep 2010 10:36:15 -0000 Message-ID: <4C8DFFBF.2060905@freebsd.org> Date: Mon, 13 Sep 2010 12:41:03 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Randall Stewart References: <4C7A7B25.9040300@freebsd.org> <4C7D0089.1020104@freebsd.org> <4C8AA863.4060908@xiplink.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , freebsd-net@freebsd.org, wollman@hergotha.csail.mit.edu, Karim Fodil-Lemelin Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 10:41:04 -0000 Based on the feedback I withdraw the proposal to remove implied connect from TCP. Instead I will look at it closer and fix any loose ends that may have come from other changes in the TCP code. Many good points have been raised and I will repeat them here again for the archives: o In FreeBSD most, if not all, protocols support implied connects, removing it from TCP would make it an outlier. o It is being used by at least one product based on FreeBSD. o It can speed up the data sending phase by sending data on the ACK after SYN-ACK. [In RFC1644 it already sent data on the initial SYN but no one is accepting that anymore.] It is important to note, though, that implied connect in TCP is non-standard and no other even remotely popular OS supports it. Thus any applications making use of it are non-portable. -- Andre On 11.09.2010 17:38, Randall Stewart wrote: > All: > > One thing to note.. when you can do an implied connection setup, the > 3-way hand shake has the potential to carry data (don't know if tcp does in FreeBSD) > on the third leg of the 3-way handshake. > > This is one of the reasons SCTP uses this.. since we often will > carry data an the third and even possibly the 4th leg of the handshake (we > have one extra leg). > > Taking this feature out of TCP will make it so we will be like all other > o/s's and the socket semantic will prevent you from doing data on the third leg.. > > ----SYN----> > <----SYN-ACK--- > ----ACK---> > > instead of > > ----SYN--> > <---SYN-ACk-- > ---ACK+DATA--> > > > In the past I have mentioned in classes I teach that TCP is capable of this but the O/S's > of the world do not allow this later behavior.. > > Just thoughts and ramblings ;-) > > R > > > On Sep 10, 2010, at 2:51 PM, Karim Fodil-Lemelin wrote: > >> On 31/08/2010 5:32 PM, Robert Watson wrote: >>> >>> On Tue, 31 Aug 2010, Andre Oppermann wrote: >>> >>>>> I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit >>>>> more. While I'm not aware of any applications depending on the semantic for TCP, I know that we >>>>> do use it for UNIX domain sockets. >>>> >>>> I don't have any plans to remove the implied connect support from the socket layer or other >>>> protocols, only from TCP. >>> >>> Right -- the implicit question is: why should TCP be the only stream protocol in our stack *not* >>> to support implied connection, when we plan to continue to support it for all other protocols? >>> >>>> For deprecating this part of the TCP API there is no documentation to the implied connect in >>>> tcp(4). In sendto(2) it doesn't differentiate between protocols and simply says: "... sendto() >>>> and sendmsg() may be used at any time." For MSG_EOF it says that is only supported for >>>> SOCK_STREAM sockets in the PF_INET protocol family. These sentences have to be corrected. >>> >>> In general, deprecating is taken to mean providing significant and explicit advance warning of >>> removal -- for example, updating the 8.x man page to point out that the feature is deprecated and >>> it will not appear in future releases of FreeBSD. >>> >>> Robert >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> Hi, >> >> For what its worth, we at Xiphos (now XipLink), are still using sendto and T/TCP and is one of the >> reasons we've chosen FreeBSD more then 10 years ago! >> >> Best regards, >> >> Karim. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >