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.
