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.
