Hi Karl, We do NAT traveral using TCP without a relay and it works through symmetric NAT pairings.
However, I think any solution that exposes the tunnel through a virtual networks adapter on which you could open socket would work for you - regardless of how that tunnel is formed? We have an SDK that you can use to identify endpoints and open a socket (no virtual network adapter). Let me know if you are interested. http://www.leafnetworks.net Let me know, Jeff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott C. Best Sent: Tuesday, August 07, 2007 9:09 PM To: theory and practice of decentralized computer networks Subject: Re: [p2p-hackers] Traversal using TCP 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 > I'm doing some independent research on P2P network architecture and > just introduced myself to this field of technology. I have a goal of > deploying web servers for use in homes. I've extracted the following > which I believe are requirements for a successful implementation: > > 7 Transport layer must be implemented as TCP. > > 7 Application layer will be over HTTP/SOAP. > > 7 Must use native TCP stack on client devices so standard browsers > can read data directly from the web server. > > 7 Ideally, solution is reliable across all NAT including symmetric, > but primarily targeting devices behind residential NATs (which I > gather is generally full and restricted cone). > > 7 Use of relay is not an option. > > 7 Use of a signaling device is totally fine. > > 7 The NAT in front of the server will need to remain in its default > configuration. > It would be extremely helpful for me to know: > > - What general components are involved in a given solution's > implementation? > - What libraries/solutions would be recommended for each component? > - How reliable the "solution" is (i.e. does it work 40% of the time? > 80%?). > > I'm familiar with STUNT, but I'm under the impression it isn't that > reliable. Any other techniques out there? Any help/advice is greatly > appreciated! > Karl _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
