Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 42184 invoked from network); 17 Nov 2005 09:07:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Nov 2005 09:07:12 -0000 Received: (qmail 29539 invoked by uid 500); 17 Nov 2005 09:07:09 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 29437 invoked by uid 500); 17 Nov 2005 09:07:08 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 29398 invoked by uid 99); 17 Nov 2005 09:07:08 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 01:07:08 -0800 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [217.79.216.190] (HELO rly01e.srv.mailcontrol.com) (217.79.216.190) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 01:08:41 -0800 Received: from c1-ex002.groupinfra.com ([213.86.115.109]) by rly01e.srv.mailcontrol.com (MailControl) with ESMTP id jAH96AUG005631 for ; Thu, 17 Nov 2005 09:06:43 GMT Received: from uk-ex003.groupinfra.com ([158.234.38.247]) by c1-ex002.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 09:06:07 +0000 Received: from uk-ex001.groupinfra.com ([158.234.68.229]) by uk-ex003.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 09:06:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5EB56.308FE332" Subject: RE: [jira] Commented: (DIRMINA-121) Per-port filter chain Date: Thu, 17 Nov 2005 09:06:26 -0000 Message-ID: <75CFC296F70A08409390004F30EF9B8506968410@uk-ex001.groupinfra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [jira] Commented: (DIRMINA-121) Per-port filter chain Thread-Index: AcXrMJBVFvS/1CyqTHSX6qWUto5rZAAI18pA From: "Irving, Dave" To: "Apache Directory Developers List" X-OriginalArrivalTime: 17 Nov 2005 09:06:21.0138 (UTC) FILETIME=[2D673320:01C5EB56] X-Scanned-By: MailControl A-05-40-01 (www.mailcontrol.com) on 10.69.0.111 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C5EB56.308FE332 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Dave, > Sorry for getting back late. I was busy writing some article for a magazine. =20 Cool - is it to do with Mina? I'd look forward to reading it if it is! :o)=20 =20 >> As an example: >> Suppose during a conversation with a client they request a certain transport encryption=20=20 >> mode should be employed.=20=20 >> This may result in the handler wanting to configure a filter supporting such encryption=20=20 >> at the start of the entire (connection) chain.=20 >> The proposed solution would only allow handlers to modify the per session chain -=20=20 >> as the other chains are shared by all other connections. > This is a great example that makes us reconsider chain copying. To resolve this we must have=20=20 > only one chain per session, and per-acceptor chain and per-port chain should be added to the per-session=20=20 > chain just before sessionCreated is invoked. It's a little bit overhead, but I think it is fine if we implement it very effectively.=20=20= =20 > Perhaps per-port and per-acceptor chains could be implemented as an array list and used only as a configuration. WDYT?=20 =20 The only problem I can think of with what you propose comes back to filter copying and NextFilter handling. If we have a list of per-acceptor and per-port filters and then combine them in to a logical chain at session creation time, dont we have the problem that - either: =20 1 - Each (per acceptor / per port) filter will need to be init'ed multiple times with multiple next filters. This would make it quite difficult for a filter implementation which wants to kick out async notifications (it might be sitting in 1000 chains: How would it know who to notify of an event? And even if it did know, it would have to have to manage each NextFilter manually. I.e: We'd be making it harder for users to implement chains) =20 or =20 2 - We'd have to find some way of copying filters =20 However, I've thought of another approach we could possibly take (later on in this mail....) =20 > The solution adds more complex API and will make users confused IMHO. =20 Are you referring to the suggestion that users could get a per-session chain by name? (E.g, session.getFilterChainBefore("acceptor")). If so then I agree - its clunky and nasty :o) =20 I've thought of something we could possibly do though - but its not 100% clear in my mind yet - so I appologise if any of this is confusing!!...... =20 Ok - we were already going to have some behind-the-scenes magic to allow chains to be hooked together by dispatching per session (to power the original chain-combining method). What if we extended it to apply per filter !! So, you start with your per-acceptor / per-port and session specific chain. Inside this, the "NextFilters" are "smart proxies": They delegate to something which manages the flow on a per-session basis. In fact, the NextFilter employed by AbstractIoFilter is already "smart" today: If filters are added or removed, things still work. This is just an extension to make this work on a per-session basis :o) =20 The user then sees a complete chain - just as if we'd copied filters - and can modify it however they choose as easily as they can today. =20 However, the chain implementation is smart. When a filter is removed or added (from the chain provided by IoSession.getFilterChain()), it adjusts the flow for that session. As the NextFilters installed to filters are "smart", things are still routed correctly. This would still mean that there is no need to init a filter multiple times or copy filters. We can still configure acceptor chains, port chains and session chains - and filters are still "reused". Its just that the routing between filters (NextFilter implementation) is now=20 smart enough to route according to the per-session flow. Hopefully that will keep the solution still very efficient. =20 How does that sound? =20 > Trustin =20 Thanks, =20 Dave=20 This e-mail and any attachment is for authorised use by the intended recipi= ent(s) only. It may contain proprietary material, confidential information = and/or be subject to legal privilege. It should not be copied, disclosed to= , retained or used by, any other party. If you are not an intended recipien= t then please promptly delete this e-mail and any attachment and all copies= and inform the sender. Thank you. ------_=_NextPart_001_01C5EB56.308FE332 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Dave,

 >  Sorry for getting back late. = I was=20 busy writing some article for a magazine.
 
Cool - is it to do with Mina? I'd look forwar= d to=20 reading it if it is! :o) 
 
>> = As=20 an example:
>> Suppose dur= ing a=20 conversation with a client they request a certain transport=20 encryption  
>>  mode should be employed.  =
>>  This may result in the handler wantin= g to=20 configure a filter supporting such encryption  =
>>  at the start of the entire (connectio= n)=20 chain. 

>>=20  The proposed solution would only allow handlers = to=20 modify the per session chain -  
>>  as the other chains are shared by all= other=20 connections.

>  This is a great example that makes us rec= onsider=20 chain copying.  To resolve this we must have  
>=20  only one chain per session, and per-acceptor chain and= =20 per-port chain should be added to the per-session  
>=20  chain just before sessionCreated is invoked.  It's= a=20 little bit overhead, but I think it is fine if we implement it very=20 effectively.   
>=20  Perhaps per-port and per-acceptor chains could be=20 implemented as an array list and used only as a configuration. =20 WDYT? 
 
The=20 only problem I can think of with what you propose comes back to filter= =20 copying and NextFilter handling.
If=20 we have a list of per-acceptor and per-port filters and then combine them in to a logical= chain at=20 session creation time, dont we have the problem that -=20 either:
 
1 -=20  Each (per acceptor= / per=20 port) filter will need to be init'ed multiple times with multiple next filt= ers.=20 This would make it quite difficult for a filter implementation which wants = to=20 kick out async notifications (it might be sitting in 1000 chains: How would= it=20 know who to notify of an event? And even if it did know, it would have to h= ave=20 to manage each NextFilter manually. I.e: We'd be making it harder for users= to=20 implement chains)
 
or
 
2 -=20 We'd have to find some way of copying filters
 
However, I've thought of another approach we could possibly t= ake=20 (later on in this mail....)
 
> The= solution=20 adds more complex API and will make users confused IMHO.
 
Are=20 you referring to th= e=20 suggestion that users could get a per-session chain by name? (E.g, session.getFilterChainBefore("acceptor")).
If=20 so then I agree - its clunky and nasty :o)
 
I've=20 thought of something we could possibly do though - but its not 100= %=20 clear in my mind yet - so I appologise if any of this is=20 confusing!!......
 
Ok -=20 we were already going to have some behind-the-scenes magic to allow chains = to be=20 hooked together by dispatching per session (to power the original=20 chain-combining method).
What=20 if we extended it to apply per filter !!
So,=20 you start with your per-acceptor / per-port and session specific chain. Ins= ide=20 this, the "NextFilters" are "smart proxies": They delegate to something whi= ch=20 manages the flow on a per-session basis. In fact, the NextFilter employed b= y=20 AbstractIoFilter is already "smart" today: If filters are added or removed,= =20 things still work. This is just an extension to make this work on a per-ses= sion=20 basis :o)
 
The=20 user then sees a complete chain - just as if we'd copied filters - and can= =20 modify it however they choose as easily as they can today.
 
However, the chain implementation is smart. When a filter is remov= ed or=20 added (from the chain provided by IoSession.getFilterChain()), it adjusts t= he=20 flow for that session.
As the=20 NextFilters installed to filters are "smart", things are still routed=20 correctly.
This=20 would still mean that there is no need to init a filter multiple times or c= opy=20 filters.
We can=20 still configure acceptor chains, port chains and session chains - and filte= rs=20 are still "reused". Its just that the routing between filters (NextFilter= =20 implementation) is now
smart=20 enough to route according to the per-session flow.
Hopefully that will keep the solution still very=20 efficient.
 
How=20 does that sound?
 
>=20 Trustin
 
Thanks,
 
Dave 


This e-mail and= any attachment is for authorised use by the intended recipient(s) only. It= may contain proprietary material, confidential information and/or be subje= ct to legal privilege. It should not be copied, disclosed to, retained or u= sed by, any other party. If you are not an intended recipient then please p= romptly delete this e-mail and any attachment and all copies and inform the= sender. Thank you.

------_=_NextPart_001_01C5EB56.308FE332--