On 14/12/09 07:28 PM, Anders Persson wrote:
Hi Darren,
My responses are inline.
On Wed, Dec 09, 2009 at 08:34:32AM +1100, Darren Reed wrote:
...
5.2
Is there any limit to how many connections can be in the ESTABLISHED TCP
state but not returned via accept because of filters?
How can I tell which sockets are in this state? netstat? something else?
For a given listener, the number of deferred connections is only limited by the
backlog size. There is no global limit on the number of deferred connections.
I'll add per-filter kstat that show how many connections are currently
deferred.
I suppose this is fine.
Some additional kstats that would be useful:
- number of times a filter is attached to a socket (maybe pasive/active
counters are different)
- number of times a filter has been detached from a socket
- number of sockets that are waiting for the filter to say it is ok
to become established
- number of sockets that are closed after the filter has been attached
but before it was able to finish its work (think connection dropped
because only "GET " was received on a http filter socket.)
From the first two, the total number of active sockets with attached
filters can be derived
Some administrative problems I can foresee:
- my web server is using socket filters, i can connect to the server
but I can't see any connections being accepted by the server.
Where is my TCP connection?
How do I know how many other TCP connections are
in a similar state?
How can I tell what state the socket is in within the filter?
Normally the way we know what state a TCP connection is in
is to use "netstat" and look for ESTABLISHED, SYN_RECEIVED,
FIN_WAIT_2, etc. This introduces a whole new set of sub-states
that we currently have no insight into. I don't know if this project
should be required to provide something that allows a filter to set
a sub-state or even how that would be observed.
8.2.1
Looking at sofop_attach, it would seem that a number of its arguments
are only used for passive opens. For example, there will be no useful
address information available for an active open. Isn't it therefore
better to have a different attach for both socket() and accept()? This
would better mirror the design elsewhere that has a callback per socket
function (bind, etc.)
I considered having separate callbacks, but I kept coming back to it being
a single event, and hence the one callback. Also, a split would not simplify
the callback for passive attach, so I would like to keep it as it is for
now.
The difference, as I see it, is that a socket filter needs to infer that
a connection is being passively opened, rather than actively opened,
via the parameters to the callback.
With different callbacks, there's no need to infer which type of open
it is and nor is there any danger to such code from changes in how
the parameters are used.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
