river-dev mailing list archives

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
implemented.
Keep thinking.
Cheers,
Peter.