Hi Sim,
Here's an idea for No.1.
The NAT-PMP protocol allows client software to request a port mapping
from the NAT Gateway, however this is for simple NAT networks, not
nested NAT and not everything supports it.
The connection from an internal host for reply packets appear as random
ephemeral ports (ports not assigned protocols by IANA) on a NAT gateway,
however this port closes after a short idle period. Then there's the
problem of network filters. We could compress the serialization byte
stream using deflate compression, I don't know if this would disguise
the stream but it would be faster.
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.
Then all I need is a method of utilising the DNS-SD from Jini / River.
Cheers,
Peter.
From http://mindprod.com/jgloss/tcpip.html
Disconnect Detection
Since TCP/IP sends no packets except when there is traffic, without
Socket.setKeepAlive( true ), it has no way of noticing a disconnect
until you start trying to send (or to a certain extent receive) traffic
again. Java has the Socket.setKeepAlive( true ) method to ask TCP/IP to
handle heartbeat probing without any data packets or application
programming. Unfortunately, you can’t tell it how frequently to send the
heartbeat probes. If the other end does not respond in time, you will
get a socket exception on your pending read. Heartbeat packets in both
directions let the other end know you are still there. A heartbeat
packet is just an ordinary TCP/IP ack packet without any piggybacking data.
When the applications are idling, your applications could periodically
send tiny heartbeat messages to each other. The receiver could just
ignore them. However, they force the TCP/IP protocol to check if the
other end is still alive. These are not part of the TCP/IP protocol. You
would have to build them into your application protocols. They act as
are-you-still-alive? messages. I have found Java’s connection continuity
testing to be less that 100% reliable. My bullet-proof technique to
detect disconnect is to have the server send an application-level
heartbeat packet if it has not sent some packet in the last 30 seconds.
It has to send some message every 30 seconds, not necessarily a dummy
heartbeat packet. The heartbeat packets thus only appear when the server
is idling. Otherwise normal traffic acts as the heartbeat. The Applet
detects the lack of traffic on disconnect and automatically restarts the
connection. The downside is your applications have to be aware of these
heartbeats and they have to fit into whatever other protocol you are
using, unlike relying on TCP/IP level heartbeats.
However, it is simpler to use the built-in Socket.setKeepAlive( true )
method to ask TCP/IP to handle the heartbeat probing without any data
packets or application programming. Each end with nothing to say just
periodically sends an empty data packet with its current sequence,
acknowledgement and window numbers.
The advantage of application level heartbeats is they let you know the
applications at both ends are alive, not just the communications software.
QCG - Sim IJskes wrote:
I'm a bit swamped at the moment, but my requirements for jini look
like this:
1) provide means to allow NAT-ed clients to provide services.
2) create an identity provisioning service
I have a way to provide issue 1 right now, but i'm not happy about it.
Its a star network with HTTP as a transport layer. The intention is to
create a service to act as a nat-service-proxy, with a mailbox style
rendezvous. The NAT-ed service polls the mailbox. The client connects
to the service-proxy. The protocol would be message based, with
messages method-call and method-reply. I'm thinking about abstracting
the serialization from a suitable transport in order to find the
message boundaries. (i'm a little suspicious: why didn't the sun jini
team do this?)
The intention for issue 2 is to provide a service whereby a client can
request an identity (or group membership) certificate and use this
certificate for incoming and outgoing connections from that point on.
Acceptance of the identity request will be done by the GUI or another
outside system, providing the acceptor with a secret in order to
verify identity via outside channels (think of bluetooth pairing).
My JXTA for Jini attempt is shelved. The JXTA production release from
a few months ago was non-functional for my deployment scenario
(HTTP-only), the HEAD release had stall problems during connection
setup. The effort seems to be big compared to building the
functionality needed with Jini alone.
Gr. Sim
P.S. for UDP a messagetype method-call-without-reply might be possible.
