Mark Huth wrote:
David Miller wrote:
From: [EMAIL PROTECTED] (David Griego)
Date: Tue, 27 Mar 2007 14:47:54 -0700
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application termination.
Signed-off-by: David Griego <[EMAIL PROTECTED]>
SO_LINGER with a zero linger time plus close() isn't working
properly?
There is no reason for this ioctl at all. Either existing
facilities provide what you need or what you want is a
protocol violation we can't do.
Actually, there are legitimate uses for this sort of API. The patch
allows an administrator to kill specific connections that are in use by
other applications, where the close is not available, since the socket
is owned by another process. Say one of your large applications has
hundreds or even thousands of open connections and you have determined
that a particular connection is causing trouble. This API allows the
admin to kill that particular connection, and doesn't appear to violate
any RFC offhand, since an abort is sent to the peer.
One may argue that the applications should be modified, but that is not
always possible in the case of various ISVs. As Linux gains market
share in the large server market, more and more applications are being
ported from other platforms that have this sort of
management/administrative interfaces.
Mark Huth
I also believe this is a useful thing to have. I'm not 100% sure this
ioctl is the way to go, but it seems reasonable. This directly
corresponds to writing deleteTcb to the tcpConnectionState variable in
the TCP MIB (RFC 4022). I don't think it constitutes a protocol violation.
As a concrete example of a way I've used this type of feature is to
defend against a netkill [1] style attack, where the defense involves
making decisions about which connections to kill when memory gets
scarce. It makes sense to do this with a system daemon, since an admin
might have an arbitrarily complicated policy as to which applications
and peers have priority for the memory. This is too complicated to
distribute and enforce across all applications. You could do this in
the kernel, but why if you don't have to?
-John
[1] http://shlang.com/netkill/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
