--- Stephen Reed <[EMAIL PROTECTED]> wrote: > Matt (or anyone else), have you gotten as far as thinking about NAT > hole punching or some other solution for peer-to-peer?
Yes, 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 looked at Skype. http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf Their approach (as of 2004) to initiate a connection is to first try UDP, and if that is blocked by a firewall, then try TCP on a high port number, and then on ports 80 and 443 which aren't usually blocked. If none of these work (like trying to contact me), then both peers have to relay messages through a supernode with a public (not necessarily static) IP address that admits at least one of these ports. I would have to continually poll supernodes to see if I have any incoming calls. This is convenient because users can run Skype without reconfiguring their firewalls. However it adds traffic to supernodes. The Skype software detects if you have a firewall/NAT, and if not, your computer automatically becomes a supernode and there is no option (as of 2004) to turn this off. This creates an incentive to install a NAT, which is the opposite of what you want. I also looked at N2N. It creates a virtual IP layer so it should work for both TCP and UDP. However it still needs supernodes with public IP addresses to set up connections. It also appears that the software needs to run at both ends. A second problem is that Skype is not truly distributed. There is a central login server. Skype traffic is encrypted with AES using public key RSA to negotiate keys. However, the login server has to validate the public keys. The problem is fundamental to public key cryptography. I can publish a public key so that anyone can send me encrypted messages that only I can read. However, this does not stop people from saying "I'm Matt and here is my public key" to read messages intended for me. The Skype login server prevents this impersonation. SSH has this problem too. To set up a secure server, I register my public key with a "trusted authority" which can vouch that I am really me by signing my key. Another authority has to vouch for it, ultimately leading to a chain of certificate authorities leading back to a root authority like Verisign or Microsoft. 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. -- 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
