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
It can, but these problems can be mitigated.
The problem with most network applications is that they don't have an automation system to keep trying to connect, or find a different route, because the internet routing mechanisms are like "hidden streets", or perhaps more like unnamed streets.
Thats the beauty of the connectionManager in jeri, it does the reconnecting for you. The 'routing' is done by a registry containing a list of 'accepting proxies' and a list of 'willing proxies'.
It is complicated by the fact that NAT was invented instead of switching to IPV6 to get more addresses. It's compounded and perhaps never going away, because NAT turns out to provide a convenient firewall.
NAT is never going away. I agree, or not in the foreseeable future. Inbound firewall blocking will stay for even longer.
I think that in the end, we should really focus on "continually connected", "bi-directional flow" sockets so that callbacks can happen on those, instead of requiring a "reconnection". The client should maintain the connection to the server. Sure, you could just connect to a proxy/relay hub too.
Mekong v2 is a continually connected conveyer belt, conveying i/o packets up and down. The connectionManager from jeri, will attempt a new connection, when connection is lost. It restarts by looking up the proxy that waits for the connection. So mekong has all the aspects you mention in the last paragraph.
