Removal of deprecated implied connect for TCP

[Robert Watson]

On Tue, 31 Aug 2010, Garrett Wollman wrote:

> In article <4C7D02BB.40300 at freebsd.org> andre at 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