Hi Dave,
> Sorry for getting back late. I was busy writing some article for a magazine.
> 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
>> 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 -
>> 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.
