RE: [discuss] How hard would it be to add a "search and load"?
"Greg Bildson" <[email protected]> Tue, 25 Jan 2005 11:46:17 -0500
| Newsgroups | gmane.network.gnutella.limewire.general |
|---|---|
| Message-ID | <[email protected]> |
One search per hour use to be our limit. We even got rid of that and have tried to get Gnutella developers like BearShare who do allow 1 automated requery per hour to get rid of that. Our newer dynamic querying algorithm makes the network quieter and it is extremely sensitive to abuse. You've got to investigate the worst case cost of employing this algorithm so you must assume that everyone on the network will do the same thing. (Why shouldn't they be just as greedy.) (1000000 users * 1 hour) /60 minutes / 60 seconds = 277.77 queries per second injected into the network if everyone employs this algorithm. Now, I can tell you that 277 queries per second is quite a fair bit. In fact, your need for some type of requerying implies that these are some kind of rare search so dynamic querying will make these searches very aggressive. This will use substantial network bandwidth as these searches hit a lot of nodes on the network (probably 50,000 at least). The question you have to answer is, would you rather have people logging into the network and doing searches that work well or would you like to have these automated queries running? I can tell you that users will leave if the network doesn't perform well so, that is why these types of automated queries damage the network. Our goal is to attempt to satisfy users that log onto the network and actually type in searches. All other use of search is extraneous and damaging. Thanks -greg > -----Original Message----- > From: Clemens Eisserer [mailto:[email protected]] > Sent: Tuesday, January 25, 2005 11:14 AM > To: Greg Bildson > Subject: RE: [discuss] How hard would it be to add a "search and load"? > > > Well, why does it destroy the network if I ask every hour or so > if maybe new results are available? > > > ------------------------- > Thanks for the compliment. > > The code is good for doing that type of thing and we use to have > a WishList > feature that did something like that. However, that kind of behavior - > searching automatically and repeatedly - is extremely damaging to the > network and we discourage all Gnutella developers from doing it. > We have to > constantly tell them that requerying and automated requerying in > particular > is extremely damaging. It doesn't take much activity from a network of a > million people to bring down the entire network. I would discourage you > from trying to do anything that requires the programmatic issuing of > queries. > > Thanks > -greg > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]]On Behalf Of Clemens Eisserer > > Sent: Tuesday, January 25, 2005 6:55 AM > > To: [email protected] > > Subject: [discuss] How hard would it be to add a "search and load"? > > > > > > Hello! > > > > First of all thank you for releasing the source of limewire - its > > just fine to have an really good open client! > > > > I would interrested in implementing a function I would describe > > with "search and load" - where you could leave limewire alone and > > it searches for the specified string on and on and downloads > > results not already downloaded. > > > > How hard would it be to implement this - and how good is the > > limewire-api seperated from the GUI? > > > > Thanks in advance, lg Clemens > > ______________________________________________________________ > > Verschicken Sie romantische, coole und witzige Bilder per SMS! > > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 > > > > _______________________________________________ > > discuss mailing list > > [email protected] > > http://www.limewire.org/mailman/listinfo/discuss > > > > > ______________________________________________________________ > Verschicken Sie romantische, coole und witzige Bilder per SMS! > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 > _______________________________________________ discuss mailing list [email protected] http://www.limewire.org/mailman/listinfo/discuss