river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: NAT traversal, Meekong Jeri, DGC
Date Mon, 27 Jun 2011 16:30:32 GMT
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.


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.

View raw message