Re: [jgroups-dev] Creating a STUNT protocol for JGroups?

Mike Jensen wrote:
> I was just curious as to what it would take to create a STUNT protocol
> for JGroups. You can read about STUNT here:
> http://nutss.gforge.cis.cornell.edu/publications.php
> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf

I read the paper this morning. My conclusion is that TCP stunning is 
impossible to implement in JGroups because (1) it requires access to 
networking stack internals (such as raw sockets or ICMP handling) and 
(2) support for all different NATs would require a lot of protocols...

However, we could implement STUN for UDP. This looks much simpler than 
TCP stunning.

This means that treemesh would be based on UDP (unicasting) as 
transport, which IMO shouldn't be an issue as JGroups provides 
reliability over UDP...

We might be able to implement stunning as a protocol (STUN), which keeps 
track of (virtual) connections for which we don't yet have a STUN 
connection yet, and punch the firewall the first time we send a message 
to a destination for which we don't yet have a connection.

> Basically it is like STUN, except it is not specific to UDP, but tries
> to punch through TCP by having a middle hosts. Long story short, I
> believe it works by simply having an open connection to a server. Then
> you have that server drop the connection and immediately have a third
> host take over that open port in the firewall. It sounds like on most
> firewalls this will let you have two natted machines have a TCP
> connection to each other.

I don't think this will work: as discussed in the paper, this will work 
only if you have the right TCP seqno for the third host, which requires 
seqno guessing. This works only if you have access to the ICMP layer and 
are able to catch the ICMP error message which contains the seqno.

> Something like this has obvious benefits for P2P as well as my
> protocol. I was hoping to show my treeMesh chat program demo in the
> next couple weeks. But in order to have chat members establish
> connections to other chat members something like this would be needed.
> Any advice as to how difficult you think this might be?

Mission impossible ! :-) At least in Java. Even if you do this in C, 
it's a hairy mess to implement...

> In order to get
> such precise control on the sockets would I need to create a new
> protocol that extends TCP? Or at a high level how might this work?
> (just trying to gauge if it is worth the effort or not right now)

I honestly believe this is NOT doable. Your best bet at STUNning is to 
use UDP as transport. Do you want to take that route ? Might actually be 
an advantage as you don't need to maintain connection tables and sockets 
plus threads...

> Alternatively, if I don't create a STUNT protocol here is what I am
> thinking I might do:
> * Have a root node that accepts unlimited connections (to function as
> the IRC bridge)

Like GossipRouter and TUNNEL... Not really P2P like (although you can 
have multiple GossipRouters and distribute the traffic among them)...

> * Use a gossip server so that multiple chat instances on the same LAN
> can establish a normal tree like structure.
>
> But I don't expect it to truly show off the benefits of the treeMesh
> doing something like this. The only other option I see is just have no
> IRC bridge, and just have the chat program only work with other LAN
> members (would use MPING for discovery then). But that's not very
> interesting!
>
> Any thoughts on the best way to demo the TreeMESH protocol?

Switch to UDP as transport *if* there are firewalls / NATs involved, and 
implement STUN. I might actually be interested in implementing STUN 
myself... :-)

> Thanks everyone. Expect an update from me in the next couple weeks to
> be sure. I am working on updating documentation, and currently just
> trying to fix some bugs with graph partitions/merging. I have also done
> some performance based testing, but want to do more. But in general it
> has (IMO) been starting to work pretty darn good.

Excellent !

Don't be shy to ping me directly (skype, IRC) if you want an interactive 
discussion !
Cheers,

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Javagroups-development mailing list