From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 08:24:02 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E49A10656E5; Thu, 9 Sep 2010 08:24:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 241248FC16; Thu, 9 Sep 2010 08:24:02 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8411846B09; Thu, 9 Sep 2010 04:24:01 -0400 (EDT) Date: Thu, 9 Sep 2010 09:24:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Garrett Wollman In-Reply-To: <201008311830.o7VIUBig022098@hergotha.csail.mit.edu> Message-ID: References: <4C7A7B25.9040300@freebsd.org> <4C7D02BB.40300@freebsd.org> <7B42D7FB-B782-4EE9-8813-BF7D3ED3274B@lurchi.franken.de> <201008311830.o7VIUBig022098@hergotha.csail.mit.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: andre@freebsd.org, net@freebsd.org 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: Thu, 09 Sep 2010 08:24:02 -0000 On Tue, 31 Aug 2010, Garrett Wollman wrote: > In article <4C7D02BB.40300@freebsd.org> andre@freebsd.org writes: > >> sendto() will not be touched or modified. It's just that on a TCP socket >> the tcp protocol will not perform an implied connect anymore. The only >> thing that changes is TCP dropping a deprecated and experimental extension >> and behaving like every other UNIXy OS. > > That's a little bit disingenuous, methinks. Support for the "deprecated and > experimental extension" -- RFC 1644 -- was dropped a number of years ago. > (Longer ago than I can easily recall.) The implict open/close mechanism is > orthogonal to the long-gone support for RFC 1644. There may be good reasons > to remove it anyway, but please don't claim that the status of RFC 1644 has > anyting to do with it. This is very much my opinion: the protocol feature and the API feature are independent, killing the protocol feature doesn't mean that we can or should remove the API feature. I suspect removing implied connect from other protocols *would* break things, and I would much rather we continued to implement the API consistently across all protocols than that it become mix-and-match. One thing that is on my plate for the next year or two is continuing the migration from the socket layer driving certain state transitions to the socket layer acting as a library for protocols in managing state transitions. This would help address some rarely-triggered race conditions that result from doing a socket-level test-and-set on so_state (and similar) before entering the protocol to propagate the change down. In general, our lock order has protocol locks before socket locks, and so it makes more sense to drive things the other way (a change I've made for the listen transitions but not for general socket state management). This sort of change might help reduce redundancy between socket and protocol code in the send / connect path as well. (My intent is not to take this as far as Linux has taken that philosophy: they share very little socket-level code between protocols, whereas I want to continue to provide an extensive library of common socket code -- on the other hand, I do want the protocol code to drive calls to the socket library, rather than having a lot of code in the socket layer driving things). Robert