Quote:
|
Originally Posted by Arevos
This is incorrect. There are a great number of P2P networks that require no centralised server. In such P2P networks, the user must connect through an IP address of a node already on the network. Often, one can find a long list of almost-always-on nodes compiled by volunteers. When given such a list, the P2P program tries each IP address in turn until it succeeds in getting at least one connection. Once a connection has been made, the P2P program can then integrate itself in an ad-hoc fashion into the network.
However, the problem with the approach is that it requires a lot of redundancy. You need at least one of the peers on the list to accept connections. In a large P2P network with millions of nodes, and a list of thousands of "gateway" IP addresses, this poses no problem. On a smaller network, more problems arise.
|
I would argue that this supports Jayme's argument actually. The list of volunteers are essentially nodes, that have chosen to behave as a centralized server (or in this case centralized servers), I guess that in essence makes them a series of de-centralized servers, but either way a lot of information needs to be known, and is usually stored in one easy to access place.
Aside from the argument of whether or not something is truly a 'centralized' server perhaps you could get around this restriction by using a pre-existing centralized server. Google Talk (Google chat?) uses an open standard, and I'd imagine if you took the time and effort layering a P2P transfer on top of the existing framework, something similar to Aol Instant Messengers (AIM) file swap.
-MBirchmeier
note: I know in early version of AIM such a transfer was possible, in addition to 'send' file functionality a 'get' file functionality could be setup as well to keep a direcotry of shared files. I believe this functionality was at one time removed for security reasons, but it may have been added back in since.