mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: IoFilter needs pre-connection callback (was: Proxy filter)
Date Mon, 11 Jun 2007 08:30:35 GMT
Hi Chris,

On 6/7/07, Chris Audley <chris.audley@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

Mime
View raw message