Nor did my reply to Darren make it through. ----- Forwarded message from Anders Persson <anders.pers...@sun.com> -----
Date: Mon, 14 Dec 2009 19:28:27 -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 Hi Darren, My responses are inline. On Wed, Dec 09, 2009 at 08:34:32AM +1100, Darren Reed wrote: > 2.1/2.2 > How do I know which socket filters are available to enable with SMF? You would use svcs(1) to list the available filters. > 3.1 > If filter "A" fails to attach and filter "B" is defined as being > "before" or "after" 'A", will "B" be attached? Yes; more below. > Similarly, will the configuration of "B" fail if "A" is not been > configured yet? No. The before/after X hints are only meant to provide an ordering mechanism, and does not enforce the existence of X. So if Y has a before/after X hint, then it would read "if X is present, then Y must be before/after X". > 3.2 > Shouldn't FILF_LIST be used with getsockopt, not setsockopt? Oops, that's a mistake in the doc; getsockopt() is used for FIL_LIST. > 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. > 6.1 > If no filter is configured, will pfiles display anything to indicate this? > Or will the line simply not be output? Nope, the line will be omitted. > 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. > 8.4.1 > Can the bypass flag be set on a programmatic filter? > If so, does an application need to know this state when calling FILF_DETACH? Yes, any filter can set the bypass flag, and it does not impact FIL_DETACH. The detach callback is only callback that will be triggered even if the bypass flag is set (which is a piece of info I need to add to the document). Thanks for the feedback, Anders ----- End forwarded message ----- Anders _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
