river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon IJskes - QCG <si...@qcg.nl>
Subject Re: internet version
Date Sun, 28 Oct 2012 20:07:28 GMT
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

View raw message