Cobalt-NAT solution integration

[KiranMutt]

Hi:

I am working on integrating the most appropriate NAT Traversal solutions for Cobalt.
In that aspect, please find the enclosed document discussing on the various approaches possible to solve the NAT issues.

Am currently exploring the libraries that support ICE ( Interactive Connectivity Establishment ) protocol to plug-into Cobalt..

Appreciate your suggestions/inputs in this regard,

--
Thanks & Regards
Kiran

[Howard Stearns-3]

I can't recall the details, but I am certain that the "WiscWorlds" and  
"Dormouse" builds (which Julian has archived at Duke) included David  
Reed's hole-punching implementation.
-Howard



On Jun 9, 2009, at 11:11 AM, Kiran wrote:

> Hi:
>
> I am working on integrating the most appropriate NAT Traversal  
> solutions for Cobalt.
> In that aspect, please find the enclosed document discussing on the  
> various approaches possible to solve the NAT issues.
>
> Am currently exploring the libraries that support ICE ( Interactive  
> Connectivity Establishment ) protocol to plug-into Cobalt..
>
> Appreciate your suggestions/inputs in this regard,
>
> --
> Thanks & Regards
> Kiran
> <Cobalt-NATInvestigation.pdf>

[Joshua Gargus-2]

Some javascript/style in this post has been disabled (why?)

Howard Stearns wrote:

I can't recall the details, but I am certain that the "WiscWorlds" and "Dormouse" builds (which Julian has archived at Duke) included David Reed's hole-punching implementation.
-Howard

Yes, IIRC it involved a middle-box introducer, which would also act as a relay if a direct introduction cannot be made.  Martin probably has the most hands-on experience with the code.

I'm perplexed by the apparently large fraction of Cobalt engineering resources that are devoted to NAT traversal.  Assume that NAT traversal was working perfectly today.... how would this help people find and collaborate in Cobalt worlds?  AFAICT, not having NAT traversal doesn't prevent anyone from collaborating with Cobalt, because no Rendezvous or Authentication infrastructure exists (I don't follow too closely, so please point me in the right direction if I'm mistaken).

The Cobalt Roadmap on opencroquet.org does list Rendezvous Infrastructure as part of the Phase I work plan (BTW, it also lists NAT traversal as "COMPLETED").  However, it seems to me that the granularity of the Roadmap is too coarse, because it is not unnecessary to work on NAT traversal and Rendezvous Infrastructure in parallel.  In fact, it is undesirable to the extent that it slows the completion of a working RI.

A functional RI would have tremendous and immediate payoffs in terms of attracting new developers, "eating your dogfood" instead of collaborating with Skype, etc.   Correct me if I'm wrong, but the (sadly defunct) Croquet Collaborative server was the closest thing yet to an always-available rendezvous point, and that's a shame. 

At its inception, Cobalt expressed an intention to encourage viral adoption.  If this is a serious aspiration, the single top priority should be to make it possible to have meaningful collaborations in Cobalt under *some* circumstances, even if this means that NATted collaboration is not possible at first.  Once this is possible, there will be a lot more motivation to solve the NAT problem because there will be an immediate, tangible benefit once the problem is solved.  Not to mention that it would be easier to design a suitable NAT solution once you have more real-world experience with Cobalt (i.e. once you know exactly what problem you're trying to solve).

Just my 2 cents. 

Cheers,
Josh

On Jun 9, 2009, at 11:11 AM, Kiran wrote:

---

Hi:

I am working on integrating the most appropriate NAT Traversal solutions for Cobalt.
In that aspect, please find the enclosed document discussing on the various approaches possible to solve the NAT issues.

Am currently exploring the libraries that support ICE ( Interactive Connectivity Establishment ) protocol to plug-into Cobalt..

Appreciate your suggestions/inputs in this regard,

-- 
Thanks & Regards
Kiran
<Cobalt-NATInvestigation.pdf>

[David P. Reed]

Please note that NAT traversal does not solve "corporate firewall
traversal" problems. Today I'd suggest that the right basis for a viral
distributed system would be accessed by TCP connections talking over
HTTP/TCP/IP, emulating AJAX-style exchanges.

One could create a few backbone nodes on Amazon EC2 and in some willing
university hosts - these nodes would just reflect messages to other
nodes, achieving broadcast.

Joshua Gargus wrote:

> Howard Stearns wrote:
>> I can't recall the details, but I am certain that the "WiscWorlds"
>> and "Dormouse" builds (which Julian has archived at Duke) included
>> David Reed's hole-punching implementation.
>> -Howard
>
> Yes, IIRC it involved a middle-box introducer, which would also act as
> a relay if a direct introduction cannot be made.  Martin probably has
> the most hands-on experience with the code.
>
> I'm perplexed by the apparently large fraction of Cobalt engineering
> resources that are devoted to NAT traversal.  Assume that NAT
> traversal was working perfectly today.... how would this help people
> find and collaborate in Cobalt worlds?  AFAICT, not having NAT
> traversal doesn't prevent anyone from collaborating with Cobalt,
> because no Rendezvous or Authentication infrastructure exists (I don't
> follow too closely, so please point me in the right direction if I'm
> mistaken).
>
> The Cobalt Roadmap on opencroquet.org does list Rendezvous
> Infrastructure as part of the Phase I work plan (BTW, it also lists
> NAT traversal as "COMPLETED").  However, it seems to me that the
> granularity of the Roadmap is too coarse, because it is not
> unnecessary to work on NAT traversal and Rendezvous Infrastructure in
> parallel.  In fact, it is undesirable to the extent that it slows the
> completion of a working RI.
>
> A functional RI would have tremendous and immediate payoffs in terms
> of attracting new developers, "eating your dogfood" instead of
> collaborating with Skype, etc.   Correct me if I'm wrong, but the
> (sadly defunct) Croquet Collaborative server was the closest thing yet
> to an always-available rendezvous point, and that's a shame.
>
> At its inception, Cobalt expressed an intention to encourage viral
> adoption.  If this is a serious aspiration, the single top priority
> should be to make it possible to have meaningful collaborations in
> Cobalt under *some* circumstances, even if this means that NATted
> collaboration is not possible at first.  Once this is possible, there
> will be a lot more motivation to solve the NAT problem because there
> will be an immediate, tangible benefit once the problem is solved.  
> Not to mention that it would be easier to design a suitable NAT
> solution once you have more real-world experience with Cobalt (i.e.
> once you know exactly what problem you're trying to solve).
>
> Just my 2 cents.
>
> Cheers,
> Josh
>
>>
>>
>>
>> On Jun 9, 2009, at 11:11 AM, Kiran wrote:
>>
>> ------------------------------------------------------------------------
>>
>>
>>> Hi:
>>>
>>> I am working on integrating the most appropriate NAT Traversal
>>> solutions for Cobalt.
>>> In that aspect, please find the enclosed document discussing on the
>>> various approaches possible to solve the NAT issues.
>>>
>>> Am currently exploring the libraries that support ICE ( Interactive
>>> Connectivity Establishment ) protocol to plug-into Cobalt..
>>>
>>> Appreciate your suggestions/inputs in this regard,
>>>
>>> --
>>> Thanks & Regards
>>> Kiran
>>> <Cobalt-NATInvestigation.pdf>
>>
>

[David Smith-36]

This is exactly right, and a far more straightforward approach. And, I might add, how it was designed.

David

On Tue, Jun 9, 2009 at 5:30 PM, David P. Reed <[hidden email]> wrote:

Please note that NAT traversal does not solve "corporate firewall traversal" problems. Today I'd suggest that the right basis for a viral distributed system would be accessed by TCP connections talking over HTTP/TCP/IP, emulating AJAX-style exchanges.

One could create a few backbone nodes on Amazon EC2 and in some willing university hosts - these nodes would just reflect messages to other nodes, achieving broadcast.

Joshua Gargus wrote:

Howard Stearns wrote:

I can't recall the details, but I am certain that the "WiscWorlds" and "Dormouse" builds (which Julian has archived at Duke) included David Reed's hole-punching implementation.
-Howard

Yes, IIRC it involved a middle-box introducer, which would also act as a relay if a direct introduction cannot be made.  Martin probably has the most hands-on experience with the code.

I'm perplexed by the apparently large fraction of Cobalt engineering resources that are devoted to NAT traversal.  Assume that NAT traversal was working perfectly today.... how would this help people find and collaborate in Cobalt worlds?  AFAICT, not having NAT traversal doesn't prevent anyone from collaborating with Cobalt, because no Rendezvous or Authentication infrastructure exists (I don't follow too closely, so please point me in the right direction if I'm mistaken).

The Cobalt Roadmap on opencroquet.org does list Rendezvous Infrastructure as part of the Phase I work plan (BTW, it also lists NAT traversal as "COMPLETED").  However, it seems to me that the granularity of the Roadmap is too coarse, because it is not unnecessary to work on NAT traversal and Rendezvous Infrastructure in parallel.  In fact, it is undesirable to the extent that it slows the completion of a working RI.

A functional RI would have tremendous and immediate payoffs in terms of attracting new developers, "eating your dogfood" instead of collaborating with Skype, etc.   Correct me if I'm wrong, but the (sadly defunct) Croquet Collaborative server was the closest thing yet to an always-available rendezvous point, and that's a shame.
At its inception, Cobalt expressed an intention to encourage viral adoption.  If this is a serious aspiration, the single top priority should be to make it possible to have meaningful collaborations in Cobalt under *some* circumstances, even if this means that NATted collaboration is not possible at first.  Once this is possible, there will be a lot more motivation to solve the NAT problem because there will be an immediate, tangible benefit once the problem is solved.  Not to mention that it would be easier to design a suitable NAT solution once you have more real-world experience with Cobalt (i.e. once you know exactly what problem you're trying to solve).

Just my 2 cents.
Cheers,
Josh

On Jun 9, 2009, at 11:11 AM, Kiran wrote:

------------------------------------------------------------------------

Hi:

I am working on integrating the most appropriate NAT Traversal solutions for Cobalt.
In that aspect, please find the enclosed document discussing on the various approaches possible to solve the NAT issues.

Am currently exploring the libraries that support ICE ( Interactive Connectivity Establishment ) protocol to plug-into Cobalt..

Appreciate your suggestions/inputs in this regard,

--
Thanks & Regards
Kiran
<Cobalt-NATInvestigation.pdf>