river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bishnu Gautam <bishn...@hotmail.com>
Subject RE: internet version
Date Fri, 02 Nov 2012 08:12:31 GMT

Hi Simon
Thats sounds great. Please upload the code in the river and also provide the documentation.
Your solution is pretty exciting.
RegardsBishnu


Bishnu Prasad Gautam


> Date: Fri, 2 Nov 2012 08:15:23 +0100
> From: simon@qcg.nl
> To: dev@river.apache.org
> Subject: Re: internet version
> 
> On 29-10-12 00:58, Gregg Wonderly wrote:
> > Clearly providing a proxy connection manger which becomes the "hub"
> > of the entire mechanism can create more problems then the single
> > problem that needs to be solved with NAT traversal or other network
> > routing.
> 
> I think you misunderstand the concept i'm working on. There is no single 
> hub. Multiple MkProxy host, can host multiple MkAcceptors. One server 
> socket behind the NAT can open multiple MkAcceptors. The MkProxy can 
> execute all kind of policy rules which could for instance limit the load 
> or the number of connections it hosts. As a MkProxy is just a plain 
> river service, one can discover all the MkProxies in a djinn. There is 
> no problem with registring a plain endpoint based service to an outside 
> reggie from behind the NAT, when the eventlistener callback is running 
> on a mekong endpoint.
> 
> It has a similar pattern as a TURN based solution, only completely based 
> on jini rpcs.
> 
> I hope all is clear now, and if not, please ask questions. I've covered 
> all the issues that you raised already in the code. If you have other 
> concerns please let us know.
> 
> Gr. Simon
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message