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 know it seems too complex to require the developer to understand "network" flow/behavior. I think a similar thought, for me, would be giving kids experience learning to drive on simulators to quickly understand the controls, but to never teach them the names of the streets, the fact that there can be one way streets, and that there are, in fact traffic control signals and signs that they have to pay attention to.
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. 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. 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. But, I think that this sort of infrastructure is part of what you "design" for your solution instead of "part of the solution" to every problem. Gregg Wonderly On Oct 28, 2012, at 3:07 PM, Simon IJskes - QCG <[email protected]> wrote: > On 28-10-12 19:20, Gregg Wonderly wrote: > >> Typically, not having two way TCP connectivity makes it harder to get >> Jini to work "completely right", but it's not required if you do >> somethings differently at the client, such as polling the LUS and > > Why should we do without twoway connectivity? Notification work just fine > over the internet. Without the twoway connectivity you cannot offer services > when you are behind a NAT router. For me this is fundamental property of > internet river. To be able to offer services, to other clients, even when you > are in a different LAN is an absolute requirement for me. > >> When the client needs to use a service, look it up again rather than >> using notifications to know that it is still available. Notifications > > I have very good results with a retrying proxy, that queries the discovery > manager, as soon as the original proxy is lost. > >> Peter (and others over the past 15 or so years, but he is the most >> recent champion of this) has talked about internet service location >> Services (maybe ServiceRegistrar, but not necessary to be so). The > > I know from my own experience, that he is not the only one. I'm trying to > pull a dead horse in this group, and interest is very low. Maybe this thread > will change that. > >> realistically with those kinds of results. Finding the right service, I >> think, is a hugely more narrowed search, and instead, is more than >> likely only a "hostname to IP address discovery" using DNS, and then >> MAYBE, a few "Item"s of look up context for version, locale or other >> very concrete needs. > > Grand ideas, but shall we start a bit smaller? A small non-public cluster of > cooperating services? We can gain experience, and later change the way we > find services. > >> What I feel the larger issue is, generally, is that people don't know >> enough about networking to use Jini in a WAN environment, because they >> just know about port 80 based hacks for firewall traversal, and how to >> configure specific routers to do that. If you really understand > > We should not confront users with networking problems, or configuration, this > would kill interest in river by developers of the end user services. > >> routing, VLANs and ports/NAT, you typically can make the "connection" to >> the other end. Then, it just becomes and issue of "authentication" and >> "authorization" to use the service on the other end right? > > With a proxy host on the internet, we can have zero-setup inbound > connections. No need to worry about that. > > Gr. Simon > > >
