On Tue, 31 Aug 2010, Garrett Wollman wrote:
In article <4c7d02bb.40...@freebsd.org> an...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
