----- Forwarded message from Anders Persson <anders.pers...@sun.com> -----
Date: Tue, 15 Dec 2009 10:50:24 -0800 From: Anders Persson <anders.pers...@sun.com> To: Darren Reed <darren.r...@sun.com> Cc: networking-discuss@opensolaris.org Subject: Re: Re: [networking-discuss] Socket filter design 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. > - 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. > 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. >>> 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. True. I'm OK with making this change. I'll update the doc. Thanks, Anders ----- End forwarded message ----- Anders _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
