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
