--- Stephen Reed <[EMAIL PROTECTED]> wrote: > Hi Matt, > > I am glad you are looking deeply into the issue of how to deploy > vastly distributed AGI. I have some follow-up questions regarding > your informative comments. > > > ...but NAT hole punching is not really a solution. I have a home > router/firewall/NAT that by default blocks all incoming traffic (TCP, > UDP, ICMP) not initiated by me. I could configure the firewall to > open > a port for P2P traffic, but in order to get a peer widely deployed, > there has to be an incentive for users to do so. > > I've read the n2n paper and downloaded their software, but not yet > actually evaluated it. All my home computers are behind the same > NAT/router/firewall (i.e. a Netgear Cable/DSL router), so I postponed > having to collaborate with someone else who is also behind a NAT. My > understanding of n2n is that, like you say, each end-user > periodically contacts a public, redundant, super node, to maintain a > lease. The client opens the TCP socket connection, and the super > node accepts the connection request. This behavior should not be a > problem with a firewall or NAT (Network Address Translation facility > in the user's router), because the end user behind the NAT has the > client role - not the server role. Then the super node can inform > each end user's client of the other's NAT-provided IP address and > port, so that the peers can directly exchange packets as though they > were servers. The key point is that initially both of them opened a > TCP socket as a client; > they did not accept a connection as a server. Only so-called > symmetric NATs would force the super node to relay every packet from > peer to peer. There is some downloadable software that will > determine whether your NAT is symmetric. Mine, like most are not. > With the advent of Skype and other P2P, VOIP (Internet phone) > services, users are purchasing NATs that are not symmetric, but > rather support the NAT hole-punching Skype employs.
The problem is not a technical one, but an economic one. People can reconfigure their firewalls to run P2P software. Your problem is to figure out how to make it worth the user's effort to do it, in addition to downloading, installing, and using your software. Skype's solution is a temporary one. Ultimately if P2P is widely deployed, networks will become more friendly to it. > Matt, given my clarification, would you then agree that you as an end > user need no firewall or router configuration beyond the defaults to > make use of n2n? Or could you please correct my understanding of the > n2n paper here. According to this paper: http://luca.ntop.org/n2n.pdf n2n emulates Ethernet on top of an application protocol like HTTP. You need a supernode with a public IP address (a server) to join a virtual network. > My plan > is deploy Texai in a distributed fashion with minimal need on > centralized infrastructure and also at the lowest possible cost. I > think that I can afford a few dedicated servers at ServerPronto for > 30 USD per month per server. Perhaps a couple of these could handle > a million Texai clients at less than 2,000 lease-renewal connections > per second apiece. I would distribute the n2n software as part of > the Texai end-user download, as it has the GPL license. A setup > wizard would inform the user if they had a symmetric NAT - that would > require replacement > before Texai could benefit them. I think there are scaling problems with n2n according to the paper. It would not work as an internet-wide Ethernet, which is what it would ultimately become. Well, it might, but I don't think that is the best approach. A central server would still be needed to set up P2P connections between clients behind NATs. For users who can't or don't want to reconfigure their firewalls, I think that you could tunnel a connection through UDP port 53 (DNS) on one end. When a peer contacts your server, you give it the IP and port of the other peer. To the firewall it looks like a DNS request and response. Of course there are many other temporary solutions with centralized servers that should be good enough to work the bugs out of your system. What you want to do is make sure there will be no barriers to switching existing users to a purely distributed system later. That will be very hard is you have a lot of users. Consider the problems Skype will have as the number of supernodes dwindles. You will probably need several different protocols (to be abandoned later) and make sure they can talk to each other. > Maybe for distributed AI you could get away with not using > encryption, > but you will still need some way to authenticate users. Otherwise > your > system is vulnerable to malicious users inserting bogus data or spam > while impersonating another source with a high reputation. > > The n2n software fully encrypts TCP messages by providing a VPN > (Virtual Private Network). So this should not be a problem right? > Texai will have to provide a user authentication facilty anyway to > attach credentials to what a user teaches it, and also to safeguard > private information designated by the user. The basic problem is that when Alice sends a message to Bob, Bob wants to make sure it is really from Alice. The standard solution is for Alice to choose a password one time and send it with every message. Bob stores the password (or better, a hash of it) for the first message it receives, then rejects any subsequent messages that don't match. You should probably do this at the application layer because you might have more than one peer on a host, or a peer could move to another host. Encryption will help protect passwords from being intercepted. -- Matt Mahoney, [EMAIL PROTECTED] ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=101455710-f059c4 Powered by Listbox: http://www.listbox.com
