directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <dave.irv...@logicacmg.com>
Subject RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 09:06:26 GMT
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