On 15/12/09 10:50 AM, Anders Persson wrote:
On Mon, Dec 14, 2009 at 09:24:54PM -0800, Darren Reed wrote:
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)
Sure.
- number of times a filter has been detached from a socket
There is already a stat that show how many sockets a filter is
attached to, so that with the two counters above should be sufficient.
Yup.
- number of sockets that are waiting for the filter to say it is ok
to become established
Right, that's the "deferred count", and I'll add that.
- 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.)
A filter can maintain its own kstats as well, and I think that this
type of counter would fit better there.
Do you have any feel for if there is a number of statistics
that all socket filters should keep track of?
And if so, should the plumbing that supports them support
a base set of stats that a socket filter can extend?
The model I'm thinking of here is ethernet drivers that all
now have a large pool of common statistics that are provided
through the gld/mii interfaces.
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.
The problems you mention above are not new, they already exist with
STREAMS and kssl. But I agree, having netstat be able to show
which connections have been deferred would be a useful debugging tool
and it's something I would consider addressing as a follow-up RFE.
Ok.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
