[jira] Commented: (DIRMINA-121) Per-port filter chain

["dave irving (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/DIRMINA-121?page=comments#action_12357772 ] 

dave irving commented on DIRMINA-121:
-------------------------------------

Would it be possible to have some clarifications on the scope of this change?
We have discussed a basic implementation which would allow builder style configuration of per sessionManager / port / session chains without filter copying - which is simple enough to implement.

However, this is restrictive for some users who need control on a per session basis over the whole chain.
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.

One option is to extend the proposed solution, as follows:

- In addition to a user being able to do session.getIoFilterChain() (which returns the session chain) they can also do session.getIoFilterChainBefore("chainName")
- I.e, IoFilterChain prePortChain = session.getIoFilterChainBefore("portChain");
- This provides a per session encapsulated chain which is inserted before the named chain.
- The implementation is almost the same as the initial solution 

This solves the use case described above. However, it may still be too restrictive for some users who want full control over the whole logical chain for a connection.

Unfortunately, I dont see a way to provide full control without breaking the current semantics of IoFilter due to the way each filter knows its location (we'd either have to make it possible to "copy" filters, or we'd have to change the way a filter knows its location).
So as it stands I cant really propose a patch which provides "full control" over the logical connection chain.

Would it be possible to clarify whether the proposed solution is acceptable - or whether we should go further to enable full control as has been requested?

I want to make sure I provide a beneficial solution :o)

Many thanks,

Dave

> Per-port filter chain
> ---------------------
>
>          Key: DIRMINA-121
>          URL: http://issues.apache.org/jira/browse/DIRMINA-121
>      Project: Directory MINA
>         Type: Improvement
>     Versions: 0.8
>     Reporter: Trustin Lee
>     Assignee: Trustin Lee
>      Fix For: 0.9

>
> MINA 0.8 provides only per-sessionmanager filter chain which is usually not so useful.  So we need to replace it with per-port filter chain like this:
> * IoFilterChain IoSessionManager.getFilterChain(SocketAddress address);
> This method will behave a little bit differently depending on it is an acceptor or a connector.  For an acceptor, address will be a bind address.  Otherwise, it will be a remote address.  I think this is reasonable enough and it will be fine if we document this explicitly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (DIRMINA-121) Per-port filter chain

[Trustin Lee <tr...@gmail.com>]

2005/11/17, Trustin Lee <tr...@gmail.com>:
>
> 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?
>

This approach will give a performance penalt if we're going to add a filter
to multiple sessions. The question is if we can afford it.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: [jira] Commented: (DIRMINA-121) Per-port filter chain

[Trustin Lee <tr...@gmail.com>]

Hi Dave,

Sorry for getting back late. I was busy writing some article for a magazine.

2005/11/16, dave irving (JIRA) <ji...@apache.org>:
>
> 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 solution adds more complex API and will make users confused IMHO.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/