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
