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 10:46:18 GMT
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