directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <nik...@trillian.se>
Subject Re: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 09:50:46 GMT
Hi,

To me this issue seems to be getting increasingly complex. Maybe it has 
been suggested before but wouldn't it be possible to define only the 
filters for a session manager and port and create the one and only 
session chain when a new session is created?

SessionManagers wouldn't have a chain anymore just a collection of 
IoFilters (or rather name to IoFilter mappings). When a new IoSession is 
to be created the chain is first created like so:

List sessionManagerFilters; // Configured at IoAcceptor/Connector 
creation time
List portFilters; // Configured at bind time
...
IoFilterChain sessionChain = new IoFilterChain();
sessionChain.addAll(sessionManagerFilters);
sessionChain.addAll(portFilters);
IoSession session = new IoSession(sessionChain);

The getFilterChain() method in IoAcceptor/IoConnector would be replaced with

List getFilters();

And when you bind you would have the method

bind(SocketAddress address, List filters, IoHandler handler);

Of course there would be an overhead when a session is created but all 
this copying and routing we've been talking about seems to be getting 
out of hand, right? And a chain is useless until it have been bound to 
an IoSession anyway.

/Niklas

Irving, Dave wrote:

> Hi Dave,
>
>  >  Sorry for getting back late.  I was busy writing some article for 
> a magazine.
>  
> Cool - is it to do with Mina? I'd look forward to reading it if it is! 
> :o) 
>  
>>> As an example:
>>> Suppose during a conversation with a client they request a certain 
> transport encryption  
>>>  mode should be employed.  
>>>  This may result in the handler wanting to configure a filter 
> supporting such encryption  
>>>  at the start of the entire (connection) chain. 
>
>>>  The proposed solution would only allow handlers to modify the per 
> session chain -  
>>>  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  
>>  only one chain per session, and per-acceptor chain and per-port 
> chain should be added to the per-session  
>>  chain just before sessionCreated is invoked.  It's a little bit 
> overhead, but I think it is fine if we implement it very effectively.   
>>  Perhaps per-port and per-acceptor chains could be implemented as an 
> array list and used only as a configuration.  WDYT? 
>  
> 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:
>  
> 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)
>  
> or
>  
> 2 - We'd have to find some way of copying filters
>  
> However, I've thought of another approach we could possibly take 
> (later on in this mail....)
>  
>> The solution adds more complex API and will make users confused IMHO.
>  
> 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)
>  
> 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!!......
>  
> 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)
>  
> 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.
>  
> 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
> smart enough to route according to the per-session flow.
> Hopefully that will keep the solution still very efficient.
>  
> How does that sound?
>  
>> 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 subject to legal privilege. It should not be 
> copied, disclosed to, retained or used by, any other party. If you are 
> not an intended recipient then please promptly delete this e-mail and 
> any attachment and all copies and inform the sender. Thank you.
>


Mime
View raw message