Re: [PATCH,RFC] explicit connection confirmation

[Lennert Buytenhek <buytenh@gnu.org>]

Hi,

netfilter, yeah, sure, 'could have', but please.

'Make it a netfilter module' is generally what people say when
they are confronted with a feature they don't like.

There was a thread about this in private mail round April this year,
in which some good points were raised.

- From the kernel point of view, doing it in netfilter would require
  more state tracking and access to the socket hashes and would be
  uglier.

- From the application writer's point of view, doing it via a socket
  option is much more intuitive, since this flag is really a socket
  property, than doing it via some extra API which would make it way
  too difficult/complex to use in existing apps.

It's worth noting that selective TCP connection acceptance was
also intended to be implemented as a socket option by the original
BSD developers.  See http://www.kohala.com/start/vanj.94jun27.txt
(link thanks to Marc Boucher).

>From the accept(2) man page on Red Hat Linux (again thanks to Marc
Boucher):

       For  certain  protocols which require an explicit confirmation, such as
       DECNet, accept can be thought of as merely dequeuing the  next  connec-
       tion  request  and  not  implying  confirmation.   Confirmation  can be
       implied by a normal read or write  on  the  new  file  descriptor,  and
       rejection can be implied by closing the new socket. Currently only DEC-
       Net has these semantics on Linux.


cheers,
Lennert



On Thu, Nov 07, 2002 at 08:36:28AM -0500, jamal wrote:

> Could you not have used netfilter for this? You have the app
> sending controls to add netfilter policies and delete them when not
> needed.
> 
> cheers,
> jamal
> 
> 
>