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