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

Thanks for your reply.  You make excellent points and I agree, I don't 
think STUNT is very doable.

I thought about using UDP, but I am not confident how my system will 
work with it.  I will spend some time playing with that today. but it 
might be a long startup time to learn the tools.  Any advice on what/how 
to force packet loss in a udp system?  Would NS2 be my best tool to 
simulate something like that?

With that said, I think it needs to be tested.  But I can't point to any 
specific reason jgroups existing reliability mechanisms wont work.  I 
expect that it will probably work fine.  Knowing this first though will 
help me decide if I want to work on a STUN protocol.

As always, thanks for your help!

Bela Ban wrote:
>
>
> 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,
>

------------------------------------------------------------------------------
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