On Wed, 13 Jul 2005 14:14:19 +0200
Ignatios Souvatzis <ignatios@cs.uni-bonn.de> wrote:

> Now I'm sure I must have misunderstood something.
> What are we talking about here? TCP, UDP, something completely different?

Yes sorry I forgot to mention it, it's for a few TCP daemons. It's not
something that my applications absolutely need, but I was wondering if
special features were already present on NetBSD to allow this, so that I
could experiment with it


Basically, like der Mouse described, it would allow a userspace TCP
daemon to in certain cases decide to not even establish the TCP
connection with a client, based on decisions such as client IP address
rate/concurrency limits or bans.


Having to interact with the firewall code for this would seem
suboptimal, unless the firewall could handle all needed case of
application-specific limits it could transparently enforce, with
possibly protocol-specific reply messages which a protocol might need
the server to send to the client, for things like:

- per-address maximum connection rate within a certain amount of time
- maximum concurrent connections from a single address
- maximum number of total connections from any address

It also implies that applications would need a specialized API to
describe needed parameters to the firewall component handling these, to
avoid needing frequent interaction with the firewall components for
every client connection event


From some google searches, it appears that some unix implement ways to
allow this through getsockopt(2) SO_GETADDR and/or ancillary messages to
obtain information about a queued connection event that can be queried
before calling accept(2)...  Of course it means using OS-specific code
in the application, but in some circumstances, for some TCP based
protocols, it could be an interesting feature perhaps.

Using raw sockets or some interraction with a tun(4)/bpf(4)-based device
would probably work, I'm not sure it's worth the trouble however, it
might be best just to continue close(2) after accept(2)...  If using
this, to not have serious performance drawbacks an API would again need
to be provided to applications to describe their limits in advance
possibly, avoiding very frequent IPC between the applications and the
device


If anyone ever used such a feature offered by another OS, I'm wondering
when unqueuing an unwanted request, what happens to the client, and if
the application can control it?  (i.e. it could possibly make the client
believe that connection was refused, it could delay it, potentially also
make it believe that it connected but connection immediately closed,
etc)  I guess that when thinking about it more, the idea doesn't look as
simple as it first appeared :)  Might actually perhaps even be
impractical (and of course, nonstandard anyways)

My messages were only an information query rather than a feature request.


Thanks again,
Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.