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 11:51:34 GMT
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.



 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.

View raw message