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: [email protected] > To: [email protected] > 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
