Karl:
Heya. While I consider myself not much more than a n00b myself,
I think it's safe to say that TCP NAT traversal requires either trickery,
or relaying. :) JXTA uses relaying, and is probably the best place to
start without rebuilding your own overlay.
cheers,
Scott
On Wed, 8 Aug 2007, Karl Garske wrote:
Hi Scott,
Thanks! Yeah, I had come across the link you supplied, and my primary
concern (if I interpreted it right) is that the initiator has to take part
in the trickery. Unfortunately, the initiator (web browser) in my scheme is
going to be really dumb and won't be interested in playing games.
I'm too much of a n00b to really understand your explanation of echo ware :)
I will look into it further and try to understand better. As far as relay is
concerned, I'd really like to avoid it. If we had to use it, I was looking
at broad architecture like JXTA where it might be easier to leverage
existing infrastructure. Any opinions on that?
Karl
On 8/7/07, Scott C. Best <[EMAIL PROTECTED]> wrote:
Karl:
Heya. EchoWare works, though it's relay-based:
ftp://ftp.echogent.com/EchoWare
It abstracts initiation of a "login session" to the
introduction/relay server, as well as initiation of a "data session"
to other logged in members. On success, echoWare returns a TCP port
value on the loopback interface that's the near end of a tunnel,
while the remote side connects to an "offloadPort", specified by
API usage. Login and data sessions support proxy traversal, and the
OpenSSL toolkit is used for content encryption. We're working on a
non-relayed UDP update, with fallback to TCP relay.
On this list, the best I've seen mentioned about non-relayed
TCP NAT traversal is Saikat Guha's work. Archive post here:
http://www1.ietf.org/mail-archive/web/midcom/current/msg03848.html
cheers,
Scott
<snip>
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
