Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Aug 2010 11:04:01 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Removal of deprecated implied connect for TCP
Message-ID:  <alpine.BSF.2.00.1008311102220.22661@fledge.watson.org>
In-Reply-To: <4C7A7B25.9040300@freebsd.org>
References:  <4C7A7B25.9040300@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 29 Aug 2010, Andre Oppermann wrote:

> When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago 
> the semantics of sendto(2) with regard to TCP sockets were changed.
>
> It became possible directly do a sendto(2) call with the target address in 
> the *to argument instead of doing a connect(2) first and subsequent write(2) 
> or send(2) calls as the standard TCP API specifies.  Optionally MSG_EOR 
> could be specified to close the connection again right again after the data 
> has been sent out.
>
> This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, 
> Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD 
> was the only OS to ever ship this.
>
> T/TCP was ill-defined and had major security issues and never gained any 
> support. It has been defunct in FreeBSD and most code has been removed about 
> 6 years ago.  The sendto(2) extended functionality is one of the last parts 
> that persisted and remained around living a zombie life.
>
> I want to remove it now because it is totally non-portable, has no known 
> users and complicates the TCP send path.  The patch is attached.
>
> If you have any objections speak up now.

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. 
Since it's a documented API, if we are going to remove it, then we need to 
go through a deprecation process, not least by marking it as a deprecated API 
in 8.x before having it vanish in 9.0.

(I won't be sorry to see the complexity go, but I'm not sure I have all the 
implications in mind as yet...)

Robert



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1008311102220.22661>