river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: NAT traversal, Meekong Jeri, DGC
Date Mon, 27 Jun 2011 23:42:56 GMT
For services with direct access to the internet, or an open listening port on a firewall, etc,
standard connections work.

For a service behind a firewall, even if it registers its proxy with an internet registrar,
cannot be contacted at all by clients on the other side of the firewall.

Stun, turn and ice are about getting the firewall to open a port, udp is the easiest to open,
tcp can be tunnelled over udp.  Once the connection is established it should work the same
as a standard socket, apart from some activity to keep it alive. This work is driven by voip.

It would be nice to make it configuration free, eg try standard connection first, if that
cannot be established, attempt stun turn ice, if that doesn't work, give up.

There's a mostly java library available called icedjava which might be worth looking into.

I'll finish concurrent policy in the next few weeks, then start looking into icedjava and
DNS-SRV based Discovery for getting river out onto the internet.  NB. We could use DNS-SRV
for locating codebase repositories too, which negates the need for expensive http replication,
although that can wait till later.

At the minimum to be useful over the internet, we need to enable network connections to be
established, this is where icedjava or something similar come in, all the existing endpoint
implementations should work on top. 

Any interested parties feel free to join in.

Cheers,

Peter.

----- Original message -----
> The use of a constraint for the end point that would apply the appropriate
> transport configuration would seem to be an easy way to cover the issue.
>
> A socket factory, since that is a pluggable mechanism, would solve the problem,
> but since for TCP, we could turn on the transport layer option, it seems to me,
> that adding a constraint, and then changing River's existing endpoints to
> support that if they can, and log an assertion when they can not, would make
> life easier for users so that they don't have to understand more about the low
> levels of River just to get a useful feature.
>
> Gregg
>
> On 6/27/2011 5:46 AM, Peter wrote:
> > Yeah, you're right.
> >
> > Thinking about it, it's probably lower level than the endpoint implementations
> > too.
> >
> > STUN, TURN and ICE is really what it's about and existing infrastructure
> > exists,  so a custom SocketFactory might be the soln, seeing as SSLEndpoint
> > doesn't depend on SSLSocketFactory this seems appropriate.
> >
> > Cheers,
> >
> > Peter.
> >
> > ----- Original message -----
> > > I just don't like incidental side-effects like these.
> > >
> > > DGC has a very specific job to do, keeping a firewall port open is a
> > > separate thing and ought to be tackled elsewhere IMHO.
> > >
> > > Simplistically, DGC is running atop a connection created via some
> > > transport protocol (e.g. http) just as the core invocation protocols
> > > do. If one were to put "keep-alive" in there, it should be at the
> > > transport level (e.g. http or tcp) not in the higher level protocols.
> > >
> > > Cheers,
> > >
> > > Dan.
> > >
> > > On 26 June 2011 21:51, Peter Firmstone<jini@zeus.net.au>  wrote:
> > > > Just wondering, could DGC be useful for keeping a port open on a firewall?
> > > >
> > > > EG: Ping an endpoint occasionally to keep it alive while a lease exists?
> > > >
> > > > The client doesn't know which port is open on a firewall, this connection
> > > > is set up by the firewall to allow replies from an external host to be
> > > > received by a client behind a firewall.
> > > >
> > > > If a client provides a handback object to a service, the service can
> > > > continue to contact the client via that handback object, while the
> > > > connection remains alive and the firewall port open.
> > > >
> > > > Thoughts?
> > > >
> > > > Cheers,
> > > >
> > > > Peter.
> > > >
> >
> >
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message