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 > > > 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: > > > > · Transport layer must be implemented as TCP. > > > > · Application layer will be over HTTP/SOAP. > > > > · Must use native TCP stack on client devices so standard > browsers > > can read data directly from the web server. > > > > · 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). > > > > · Use of relay is not an option. > > > > · Use of a signaling device is totally fine. > > > > · 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
