Per-port filter chain

• Key: DIRMINA-121
• Type: Improvement
• Status: Closed
• Resolution: Won't Fix
• Priority: Major
• Assignee: Trustin Lee
• Reporter: Trustin Lee
• Affects Version/s: 0.8.0
• Fix Version/s: 0.9.0

Description

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.

Comments

[dave irving]

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

[Niklas Therning]

Reassigning to Trustin since he's already working on this issue.

[Trustin Lee]

DIRMINA-131 resolves this issue indirectly.