river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: roadmap
Date Mon, 01 Feb 2010 13:16:14 GMT
Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> If we have a private service behind a NAT gateway open a connection 
>> to a public remote host and keep it open by utilising a heartbeat 
>> (empty packet sent on a regular basis during idle periods), the 
>> public host can maintain the connection also by using a heartbeat. 
>> While the private service is in contact with the host, the public 
>> host can be a proxy service for the host. By utilising DNS-SD the 
>> public host can utilise all of its available free ports to act as 
>> proxy services for private service instances, these could be 
>> registered as DNS-SD Jini services where they can be discovered. We 
>> could call this a listening post Service. The private services could 
>> upload simple reflective proxies to the listening post service. The 
>> DNS-SD could be maintained using Dynamic Update Leases When a 
>> connection is lost, the private service can re instantiate it and re 
>> register it with a DNS Dynamic Update Lease.
> Thanks. You raised some interesting issues. Never thought about the 
> serviceproxies. You only need a serviceproxy when you want to switch 
> endpoint technologies. If we have a new message based endpoint 
> implementation, you could create a endpointproxy with a receive queue 
> of size 0, and not bother with a serviceproxy.
> (hmm, again it sounds like a VPN implementation over Jini.)
> Gr. Sim
Similar to a VPN, but without the Private Part, VPN's use IPSec, which 
is a low level OS kernel and router implementation that TCP/IP utilises 
which require forward planning and administration.  Instead we could 
communicate over ordinary public networks without any special network 
admin intervention.  This does raise privacy issues though for 
serialization or message streams, however secure JERI has mechanisms to 
handle those.

That is of course if Serialization is used for communication.  
Compressed Serialized binary data is the fastest way to communicate over 
bandwidth restricted and high latency networks.  For smart proxy 
implementations we would want the client to be able to download the 
marshalled smart proxy from a lookup service and download the bytecode 
from a codebase service (it would be easier if the code base is public), 
where the smart proxy itself uses its internal reflective proxy (RMI 
JERI) to communicate with the private service via the listening post.  
The listening post would just be relaying the methods / messages while 
keeping the communication lines (NAT gateway ports) open between it, the 
smart proxy and its server.

Perhaps JERI itself could utilise some sort of Relay listening post service?

I have no idea at the moment how the Java interfaces for this might be 

Keep thinking.



View raw message