Hi Jeff, I'm definitely interested. Where can I read more about the techniques you mentioned? I'm a total n00b :) I'll definitely look into the SDK further and let you know what I think. Thanks!
Karl On 8/8/07, Jeff Capone <[EMAIL PROTECTED]> wrote: > > 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 >
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
