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 -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
