IoFilter needs pre-connection callback (was: Proxy filter)

[Chris Audley <ch...@beacon-cs.com>]

My question is, how can MINA be modified to make it possible for filters
to participate in the session before the connection is open and to
modify the parameters used to open the connection if necessary.

Yes, you've described how I can work around MINA's limitations in this
area to get a reasonably functional version of my proxy filter.
However, it is just that, a work around, and it substantially cripples
the proxy filter.

Consider the scenario where someone needs to be able to tunnel through
multiple proxies, for example one at the perimeter of the client network
and another at the perimeter of the server network.  If the proxy filter
didn't require a special IoConnector to work correctly, I could just
place multple instances of the filter in my filter chain and I'm off to
the races.  This isn't a theoretical question for me, I'm faced with
exactly this situation.

I have no problem figuring out a why to hack what I need together.  What
I would like is to find a way that MINA could be enhanced so that my
filters can be made generic enough to be added to the distribution.  It
is not uncommon for people to ask for such a filter on the mailing list.
Now that AsyncWeb is being added with most of the components necessary
to implement web proxy tunnelling, I'd like to see MINA include this
incredibly valuable -- and for many developers, necessary --
functionality.

How can MINA best support this functionality?  I think an additional
callback in IoFilter is needed.  In the case of the proxy filters, the
filter needs to be able to specify what the remote address should be
based on the service address.  Each proxy filter needs to see the
original service address to decide which proxy to use or even whether to
use the proxy (for example, maybe it doesn't proxy for local sub-nets).
It will also need to be able to determine what the remote address is
when "nextFilter" returns -- in case it was modified by another proxy
filter -- so it knows what address to connect to through the proxy.
Finally, it must be able to report what its has established as the
remote address for any proxy filters behind it in the chain.

Does anyone have a better idea?  Any thoughts on the best way to achieve
the requirements I've outlined?

-----Original Message-----
From: Niklas Therning [mailto:niklas@trillian.se] 
Sent: Thursday, June 07, 2007 2:54 AM
To: dev@mina.apache.org
Subject: Re: Proxy filter

Chris Audley wrote:
> I'd like to implement some proxy filters for MINA, filters that would 
> handle the details of opening a connection through a web or socks
proxy.
> The problem is, MINA filters have no influence over how the session is

> opened.  How can MINA be extended to give filters the opportunity to 
> redirect a session to a proxy address?
>
>   
Hi,

I guess you could implement an IoConnector to accompany your filter. The
IoConnector would need a SocketConnector to delegate to. When connect()
is called it will modify the remote address to point to the proxy
instead and then call connect() on the SocketConnector. It would also
add your proxy filter to the filter chain when a connection to the proxy
has been established. The proxy filter would then take care of the
authentication and initial handshake much like the SSLFilter does. Once
the proxy has established a connection to the original remote address
the proxy filter will have to notify the ConnectFuture returned by the
proxy IoConnector and call sessionCreated/sessionOpened.


--
Niklas Therning
www.spamdrain.net

Re: IoFilter needs pre-connection callback (was: Proxy filter)

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

Hi Chris,

On 6/7/07, Chris Audley <ch...@beacon-cs.com> wrote:
> My question is, how can MINA be modified to make it possible for filters
> to participate in the session before the connection is open and to
> modify the parameters used to open the connection if necessary.
>
> Yes, you've described how I can work around MINA's limitations in this
> area to get a reasonably functional version of my proxy filter.
> However, it is just that, a work around, and it substantially cripples
> the proxy filter.
>
> Consider the scenario where someone needs to be able to tunnel through
> multiple proxies, for example one at the perimeter of the client network
> and another at the perimeter of the server network.  If the proxy filter
> didn't require a special IoConnector to work correctly, I could just
> place multple instances of the filter in my filter chain and I'm off to
> the races.  This isn't a theoretical question for me, I'm faced with
> exactly this situation.
>
> I have no problem figuring out a why to hack what I need together.  What
> I would like is to find a way that MINA could be enhanced so that my
> filters can be made generic enough to be added to the distribution.  It
> is not uncommon for people to ask for such a filter on the mailing list.
> Now that AsyncWeb is being added with most of the components necessary
> to implement web proxy tunnelling, I'd like to see MINA include this
> incredibly valuable -- and for many developers, necessary --
> functionality.
>
> How can MINA best support this functionality?  I think an additional
> callback in IoFilter is needed.  In the case of the proxy filters, the
> filter needs to be able to specify what the remote address should be
> based on the service address.  Each proxy filter needs to see the
> original service address to decide which proxy to use or even whether to
> use the proxy (for example, maybe it doesn't proxy for local sub-nets).
> It will also need to be able to determine what the remote address is
> when "nextFilter" returns -- in case it was modified by another proxy
> filter -- so it knows what address to connect to through the proxy.
> Finally, it must be able to report what its has established as the
> remote address for any proxy filters behind it in the chain.
>
> Does anyone have a better idea?  Any thoughts on the best way to achieve
> the requirements I've outlined?

IoFilter was not designed to replace the connection itself when it was
born.  I can't think of any easy way to implement a proxy with an
IoFilter.  If someone used an IoFilter to implement a proxy, it must
be just a work around as you pointed out.

A possible workaround is to program the proxy filter to wrap the
created IoSession instance so all requests and session information are
override, but this approach has a few problems that 1) the filter has
no control over what ConnectFuture returns and 2) you have to specify
the address of the proxy server in connect() call, which is not
transparent at all.

For now, I can't think of any way to implement a reusable proxy as an
IoFilter.  It's like you can't create a proxy by wrapping existing
InputStream and OutputStream; you have to provide a SocketFactory.

I'd suggest you to create an IoConnector implementation that wraps
another IoConnector.  For example:

    ProxyConnector connector = new ProxyConnector(
                                       new SocketConnector(), proxyAddress);
    connector.connect(...);

In the example above, ProxyConnector could use its underlying
SocketConnector to connect to the proxyAddress and intercept and
filter  all events from the SocketConnector using ProxyConnector's
internal IoHandler implementation.

Moreover, ProxyConnector can be used with various transports such as
UDP and serial.

WDYT?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6