Slashdot Mirror


Mathematical Analysis of Gnutella

jrp2 sent in a paper written by one of Napster's founding engineers. It is a mathematical evaluation of Gnutella discussing why the network won't be able to scale up to any reasonable size. I have been impressed with Gnutella in the past, and have wondered along these same lines in the past.

8 of 332 comments (clear)

  1. The Logarithmic value of the messages exchanged ! by Khalid · · Score: 5, Interesting

    The problem is not that difficult, if you want Gnutella to scale, then you need to avoid the exponential explosition of the number of messages exchanged between the clients as their number grows. The only solution is to structure the network by using "super clients" or "servants" or "super nodes", call them what you want, the later is what KaZaa and Morphus have accomplished; this makes the number of messages exchanged grows in a logarithmic way (this is an outrageous simplification of course, but gives an idea). There are many such expriments with Gnutella two with those ideas, this is what BearShare is trying to do.

  2. Growth of network relates to negative attention by totallygeek · · Score: 3, Interesting
    Everyone knows that Napster was basically a glorified DCC engine rip-off from IRC days of file trading. It made IRC file sharing easy for the average computer user. With the death of Napster as everyone knew it, you still see #mp3 and #mp3tunes and the like on IRC trading files person-to-person like Metallica never existed. I think that when something explodes in popularity you get too many bad people joining in ruining things for the users that are not abusers. When so many people jump on a bandwagon, you get media attention for wrong-doing and that is where the death nail is driven.


    Look at ICQ. It was fairly decent as an instant messaging client until the numbers hit one million or so and then it needed to control everything under the sun and companies could spam through it. File sharing happens through it all the time too.


    I don't care if Gnutella cannot scale to the levels that Napster saw. Smaller is better in my opinion!

  3. gnutella by flynt · · Score: 3, Interesting

    On the topic of this program, a more current story running on msnbc.com right now is telling how it is becoming a severe security risk for users of the program. Here is the article.

  4. Is there a limit to the gnutella horizon? by eyefish · · Score: 3, Interesting

    I'm not very familiar with the deep technical details of Gnutella, but isn't there a limit on how far the "horizon" is (i.e.:how many users near by you can see)? If this is correct, all the mathematics here presented apply only in theory and not in practice, as what will happen is that (1) most queries will not be relayed past a "reasonable horizon", and (2) there exists a good (or high?) probability that as long as you're searching for "popular" files, that you will eventually find them.

    Because of this basic and simple observation, I do not foresee gnutella to die anytime soon because of scalability reasons alone (however copy-protection issues are another story).

    Again let me stress that my observation here is based on the strong assumption that the "search horizon" is "reasonable sized" so as not to have to search the whole gnutella network.

  5. who is the author of this paper? by mozkill · · Score: 3, Interesting

    its important to know that the author of this paper is Jordan Ritter, who is the co-founder of Napster.

    --

    -- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
  6. Re:The Logarithmic value of the messages exchanged by Lumpy · · Score: 3, Interesting

    and I hate to say this, but take an idea from the windows networking world... each machine has an election to see who is going to be the master browser (based on average connected and up times.. the clients that are up and serving the longest and with the shortest down times historically) then we have the next few building the same master browser database but sitting dormant (just listening and cacheing) until the master browser disappears, then the next highest pipes up and says "ohhh lookie me!" thus keeping a master server up (and that master server could load balance with the sub servers by just sending a "busy use 127.0.0.2 or 127.0.0.3" back to the client.

    it could be fixed, and made powerful, self scaling.

    --
    Do not look at laser with remaining good eye.
  7. Freenet has addressed this issue from day one by Sanity · · Score: 3, Interesting
    The scalability issues with Gnutella are clear to anyone who understands how it works. From day one, Freenet was designed with scalability as a core goal. In Freenet, the number of nodes involved, and the time required to retrieve a piece of information, scales logarithmically as the size of the network increases.

    A good analogy might be a detective trying to find a suspect for a crime. The Gnutella approach is akin to going on TV and asking everyone in the area to let you know if they know who did it. It may work once, but the more you do it, the less effective it is. Freenet works as detectives do normally, they gradually home in on their suspect by gathering information, and using that information to refine their search.

    Some say that Freenet only achieves this scalability because it doesn't do the type of "fuzzy" search Gnutella does. You need to know exactly what you are looking for in Freenet to find it. This isn't true, the Freenet searching algorithm can be generalised to allow fuzzy searching. While this has not yet been demonstrated in practice, it is definitely possible in theory.

    It always amazes me that people continue to lament flaws in many current P2P architectures when Freenet has incorporated solutions to those problems almost from its inception.

    Disclaimer: I am Freenet's architect and project coordinator, so you could be forgiven for thinking I am biased, but you are free to review our papers and research to decide for yourself.

  8. Re:The Logarithmic value of the messages exchanged by Metrol · · Score: 3, Interesting

    Not if you couldn't predict which machines on the net would act as those supernodes. If, like another poster mentioned, machines that met a certain criteria (bandwidth, storage, time on line, whatever) simply won an election to act as a node, there's no single point to shut down. Shut down one supernode, the others are informed that a replacement is needed and another election is called for.

    Following an election, the supernodes update the clients as to the lookup machines. I suppose you could even have it where if all the supernodes were shut down that an entirely new election process takes place creating a new set of supernodes. Kind of like having a DNS server setup where any machine can act as one of the root servers based on a criteria based election by those machines doing a lookup.

    Way too much for my wee brain to work out all the details on. Sounds good in theory anyway :)

    --
    The line must be drawn here. This far. No further.