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<j...@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.