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-unsubscr...@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-unsubscr...@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-unsubscr...@freebsd.org"
_______________________________________________
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"
