Gnutella at One Year
transient writes: "Gnutella's first birthday passed quietly about 10 days ago. An OpenP2P article reflects on the Gnutella network as a transient extension of the Web, since Gnutella peers use HTTP for file transfer and are essentially Web servers. Seems the network keeps evolving; there's some discussion of the new BearShare Defender and more info on the recent Gnutella virus. If Gnutella peers are Web servers, wouldn't that make Gnutella users who share files equivalent to Web site publishers, with the same responsibilities?"
If easy to program, easy to implement multicast were available, gnutella would've used it and not been nearly as poor in the scalability department. Gnutella is basically a layer 5 implementation of anysource multicast that uses flooding to get its job done.
If anybody is interested, I talk to Radia Perlman at IETF 50 last week, and we would like to try to form a working group around making an RFC out of the simple multicasting protocol she describes in the last chapter of her book 'Internetworking'.
Need a Python, C++, Unix, Linux develop
As a straight-peer-to-peer network grows, it becomes saturated with traffic. Requests are sent, propagated, and choke the entire network of peer-to-peer clients, usually at the lowest bandwith level. Since there is no central coordinating system to handle the search requests, you eventually get a network that is ass slow and unable to perform to expected levels. If you try to run this through an established client server system, lawyers decend like flocks of carrion birds. So it seems to me the fix is a hybrid network of servers that are promoted up from a pool of high bandwith connections, organized like resistance cells. These client machines would only talk to an upper level system, transferring a list of songs on the system to its cell leader. This cell leader would be part of a higher-level cell, and would send data about what was in its cell to a higher level server. Eventually, you hit the top level where you would have a ring of systems on very high bandwith connections.
Search requests would hop to the top level servers, who would talk to each other and fire back the answer. Then the two (client) machines would start swapping data. These top level machines would be updated from below with fresh data, updating their search pool dynamically.
As clients come online, they would find a server, report what they have in their swap folder, and start sharing data. requests for searches would only go to the highest bandwith systems, and then only those that are willing to serve in this capacity. If you come online with a nice fast machine, with a fat network pipe, you can become part of the search network.
Obviously, there would need to be some method of pointing clients to servers, especially if the servers were to dynamically drop on and off the network. I envision that once the sofware determines that you qualify to be a server, and you check that you do want participate, it would set you up as a backup server for a functioning system. when that system drops from the network, your machine would find another comperable system and set it up as a backup.
Any thoughts on this? Is it already being done? Should I stop smoking the crack? I know that this would be a nontrivial problem to set up, but it seems that it would remain rather uncentralized and chaotic, but not be as prone to choking as gnutella is.
The problem I see is not whether the protocol itself can scale, we are seeing numerous "tweaks" that will allow this ( Clip2's Reflector and Bearshare.net's forthcoming 3.0.0 "Defender" release) What I see as the problem is the splintering and added features being incorporated by the different Gnutella Clients: Gnotella has added "Improved bitrate scanning", BearShare and Limewire's Firewall Detection, as well as other "extraneous" features, that add information to the gnutella packets. How long will it be before these clients cause sufficient incompatibility that seperate, client specific networks arise? What we really need is an agreement between the different developers to pass on these extra packets, or agree on a central "feature set". I am not advocating that we do away with the myriad gnutella clinets, I think there variety and different personalities are great. I just don't want to see the community splinter through incompatibility issues.
-OctaneZ
(What I would really like to see is a native applications similar to Clip2's reflector for both WIN32 and Linux that serves as a "network server" only, that uses low CPU and large numbers of connections for people who believe in the Gnutella idea and are graced with highspeed connections.)
Yeah, that seems about how long I've been waiting for this file to download.
:)
Stupid Cheap Guitars
Wow one year? In net fads years, that is like what, middle aged?
I remember the old alpha days, where nothing would work and hardly anything would download, yup glad those days are gone.
--Joey