You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/09/30 21:10:08 UTC
Meta Transport: an idea on implementing reconnection and proxy
Hi everyone,
As you already noticed, I am working very hard to roll out MINA
2.0.0-M1 these days. There are only 16 issues left now. Any help is
appreciated.
The most challenging issues are reconnection and proxy. Both are
related with client-side applications. I thought a lot of these
issues and ended up to this idea: creating meta transports.
A meta transport is a transport that wraps other transport
implementation(s) to implement a certain additional feature. For
example, we could implement automatic reconnection like the following:
SocketConnector c = new SocketConnector();
c.setDefaultRemoteAddress(...);
ReconnectingConnector connector = new ReconnectingConnector(c);
For proxying:
SocketConnector c = new SocketConnector();
ProxyingConnector connector = new ProxyingConnector(
c, new InetSocketAddress("proxyserver", 8080));
It's nothing more than just classic decorator pattern, but it has a
big advantage than other approaches like defining additional extension
point in that:
* it's simple from user point of view
* meta transport implementations can work virtually with any transports:
** proxy + NIO socket
** proxy + APR socket
** reconnect + proxy + NIO socket (meta-meta-transport)
I didn't try to implement something yet, but considering our API
flexibility, it shouldn't affect the core API at all. WDYT? Does it
make perfect sense?
Thanks for the feed back in advance,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Meta Transport: an idea on implementing reconnection and proxy
Posted by Mike Heath <mh...@apache.org>.
This is exactly how I was thinking of implementing proxy support. I
hadn't given the ReconnectingConnector much thought but I think this
type of solution would work very well.
I think it does indeed make perfect sense.
-Mike
Trustin Lee wrote:
> Hi everyone,
>
> As you already noticed, I am working very hard to roll out MINA
> 2.0.0-M1 these days. There are only 16 issues left now. Any help is
> appreciated.
>
> The most challenging issues are reconnection and proxy. Both are
> related with client-side applications. I thought a lot of these
> issues and ended up to this idea: creating meta transports.
>
> A meta transport is a transport that wraps other transport
> implementation(s) to implement a certain additional feature. For
> example, we could implement automatic reconnection like the following:
>
> SocketConnector c = new SocketConnector();
> c.setDefaultRemoteAddress(...);
> ReconnectingConnector connector = new ReconnectingConnector(c);
>
> For proxying:
>
> SocketConnector c = new SocketConnector();
> ProxyingConnector connector = new ProxyingConnector(
> c, new InetSocketAddress("proxyserver", 8080));
>
> It's nothing more than just classic decorator pattern, but it has a
> big advantage than other approaches like defining additional extension
> point in that:
>
> * it's simple from user point of view
> * meta transport implementations can work virtually with any transports:
> ** proxy + NIO socket
> ** proxy + APR socket
> ** reconnect + proxy + NIO socket (meta-meta-transport)
>
> I didn't try to implement something yet, but considering our API
> flexibility, it shouldn't affect the core API at all. WDYT? Does it
> make perfect sense?
>
> Thanks for the feed back in advance,
> Trustin
Re: Meta Transport: an idea on implementing reconnection and proxy
Posted by peter royal <pr...@apache.org>.
On Sep 30, 2007, at 3:10 PM, Trustin Lee wrote:
> A meta transport is a transport that wraps other transport
> implementation(s) to implement a certain additional feature. For
> example, we could implement automatic reconnection like the following:
really really late +1 :)
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Meta Transport: an idea on implementing reconnection and proxy
Posted by Mark <el...@gmail.com>.
I give this a huge +1.
I think one of MINA's greatest strengths is that you can write different
systems very easily. Adding this to the API would make things much easier.
Proxy support is something that I often look for from MINA and this would be
a very welcome addition.
On 9/30/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi everyone,
>
> As you already noticed, I am working very hard to roll out MINA
> 2.0.0-M1 these days. There are only 16 issues left now. Any help is
> appreciated.
>
> The most challenging issues are reconnection and proxy. Both are
> related with client-side applications. I thought a lot of these
> issues and ended up to this idea: creating meta transports.
>
> A meta transport is a transport that wraps other transport
> implementation(s) to implement a certain additional feature. For
> example, we could implement automatic reconnection like the following:
>
> SocketConnector c = new SocketConnector();
> c.setDefaultRemoteAddress(...);
> ReconnectingConnector connector = new ReconnectingConnector(c);
>
> For proxying:
>
> SocketConnector c = new SocketConnector();
> ProxyingConnector connector = new ProxyingConnector(
> c, new InetSocketAddress("proxyserver", 8080));
>
> It's nothing more than just classic decorator pattern, but it has a
> big advantage than other approaches like defining additional extension
> point in that:
>
> * it's simple from user point of view
> * meta transport implementations can work virtually with any transports:
> ** proxy + NIO socket
> ** proxy + APR socket
> ** reconnect + proxy + NIO socket (meta-meta-transport)
>
> I didn't try to implement something yet, but considering our API
> flexibility, it shouldn't affect the core API at all. WDYT? Does it
> make perfect sense?
>
> Thanks for the feed back in advance,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
--
..Cheers
Mark
Re: Meta Transport: an idea on implementing reconnection and proxy
Posted by Lóránt Pintér <lp...@metacortex.hu>.
Hi!
The decorator stuff seems really cool to me. :)
However, I'd vote for supporting proxyHost and such, because there are a
lot of legacy systems out there moving to MINA. When they finally
migrate to MINA, their users don't really want to know about the change,
and don't expect changes in the configuration of the system.
I think all of these systems will then create something like
LegacyProxyConnector inherited from ProxyingConnector, and set the proxy
parameters from proxyHost etc. As I think a lot of people would
implement this redundantly, MINA could have it out of the box as well.
Regards,
Lóránt
Maarten Bosteels wrote:
> I agree with everybody else that the decorator pattern is an elegant solution.
> About system properties, I agree with Trustin: I don't think we should
> support that.
>
> Maarten
>
> On 10/2/07, Trustin Lee <tr...@gmail.com> wrote:
>> On 10/2/07, Niklas Therning <ni...@trillian.se> wrote:
>>> Yes, I think this is the way to go about implementing this kinds of
>>> things. This is similar to what was suggested the last time the proxy
>>> issue came up on the mailing list
>>> (http://www.nabble.com/Proxy-filter-tf3880454.html).
>> How did you find that thread? :)
>>
>>> Now, one thing we should consider is whether we want to support
>>> specifying proxyHost, proxyPort via system properties, just like Socket
>>> does. In that case I don't think it will be as simple as wrapping like
>>> suggested above. Maybe we could support this by having some kind of
>>> factory which looks at the system properties?
>> I agree with you that things will get complicated with system
>> properties. The questions is, do we really need to support system
>> properties? If a user uses a factory like Spring, he or she could
>> configure proxied connection very easily.
>>
>> Trustin
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> PGP Key ID: 0x0255ECA6
>>
>
Re: Meta Transport: an idea on implementing reconnection and proxy
Posted by Maarten Bosteels <mb...@gmail.com>.
I agree with everybody else that the decorator pattern is an elegant solution.
About system properties, I agree with Trustin: I don't think we should
support that.
Maarten
On 10/2/07, Trustin Lee <tr...@gmail.com> wrote:
> On 10/2/07, Niklas Therning <ni...@trillian.se> wrote:
> > Yes, I think this is the way to go about implementing this kinds of
> > things. This is similar to what was suggested the last time the proxy
> > issue came up on the mailing list
> > (http://www.nabble.com/Proxy-filter-tf3880454.html).
>
> How did you find that thread? :)
>
> > Now, one thing we should consider is whether we want to support
> > specifying proxyHost, proxyPort via system properties, just like Socket
> > does. In that case I don't think it will be as simple as wrapping like
> > suggested above. Maybe we could support this by having some kind of
> > factory which looks at the system properties?
>
> I agree with you that things will get complicated with system
> properties. The questions is, do we really need to support system
> properties? If a user uses a factory like Spring, he or she could
> configure proxied connection very easily.
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: Meta Transport: an idea on implementing reconnection and proxy
Posted by Trustin Lee <tr...@gmail.com>.
On 10/2/07, Niklas Therning <ni...@trillian.se> wrote:
> Yes, I think this is the way to go about implementing this kinds of
> things. This is similar to what was suggested the last time the proxy
> issue came up on the mailing list
> (http://www.nabble.com/Proxy-filter-tf3880454.html).
How did you find that thread? :)
> Now, one thing we should consider is whether we want to support
> specifying proxyHost, proxyPort via system properties, just like Socket
> does. In that case I don't think it will be as simple as wrapping like
> suggested above. Maybe we could support this by having some kind of
> factory which looks at the system properties?
I agree with you that things will get complicated with system
properties. The questions is, do we really need to support system
properties? If a user uses a factory like Spring, he or she could
configure proxied connection very easily.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Meta Transport: an idea on implementing reconnection and proxy
Posted by Niklas Therning <ni...@trillian.se>.
Trustin Lee wrote:
> Hi everyone,
>
> As you already noticed, I am working very hard to roll out MINA
> 2.0.0-M1 these days. There are only 16 issues left now. Any help is
> appreciated.
>
> The most challenging issues are reconnection and proxy. Both are
> related with client-side applications. I thought a lot of these
> issues and ended up to this idea: creating meta transports.
>
> A meta transport is a transport that wraps other transport
> implementation(s) to implement a certain additional feature. For
> example, we could implement automatic reconnection like the following:
>
> SocketConnector c = new SocketConnector();
> c.setDefaultRemoteAddress(...);
> ReconnectingConnector connector = new ReconnectingConnector(c);
>
> For proxying:
>
> SocketConnector c = new SocketConnector();
> ProxyingConnector connector = new ProxyingConnector(
> c, new InetSocketAddress("proxyserver", 8080));
>
> It's nothing more than just classic decorator pattern, but it has a
> big advantage than other approaches like defining additional extension
> point in that:
>
> * it's simple from user point of view
> * meta transport implementations can work virtually with any transports:
> ** proxy + NIO socket
> ** proxy + APR socket
> ** reconnect + proxy + NIO socket (meta-meta-transport)
>
> I didn't try to implement something yet, but considering our API
> flexibility, it shouldn't affect the core API at all. WDYT? Does it
> make perfect sense?
>
> Thanks for the feed back in advance,
> Trustin
>
Yes, I think this is the way to go about implementing this kinds of
things. This is similar to what was suggested the last time the proxy
issue came up on the mailing list
(http://www.nabble.com/Proxy-filter-tf3880454.html).
Now, one thing we should consider is whether we want to support
specifying proxyHost, proxyPort via system properties, just like Socket
does. In that case I don't think it will be as simple as wrapping like
suggested above. Maybe we could support this by having some kind of
factory which looks at the system properties?
--
Niklas Therning
www.spamdrain.net