Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   Open Discussion topics (https://www.gnutellaforums.com/open-discussion-topics/)
-   -   About Limewire (https://www.gnutellaforums.com/open-discussion-topics/20255-about-limewire.html)

Sleipner May 9th, 2003 06:36 AM

About Limewire
 
It starting to get clear what direction Limewire is going with their client, and its not for large public network such as Internet. But rather smaller local Intranets to search for local stuff such documents and so on, everything points to that which explains the low traffic profil they use, but also the extremly low horizon that you get with Limewire on Internet.

And they seems to refuse to change both network traffic and horizon to the better for us want to use Limewire on Internet.

Im dissapointed, that the dont state that more thoroughly.

Tetsuo May 9th, 2003 07:23 AM

Quote:

It starting to get clear what direction Limewire is going with their client, and its not for large public network such as Internet.
On the contrary. The truth is, LimeWire does not work very well for intranets without modifying the source code.

Quote:

And they seems to refuse to change both network traffic and horizon to the better for us want to use Limewire on Internet.
Last version (2.9.x) moves from 15kb/s outgoing message bandwidth for ultrapeers down to 8kb/s outgoing bandwidth, while improving the search horizon substantially. However, to reduce the traffic, LimeWire has limited the number of search results to return.

(One problem might be, that if a new LimeWire node connects to a Morpheus/Gnucleus or MyNapster ultrapeer it will return virtually no search results at all, due to the low performance of GnucDNA based ultrapeers).

Sleipner May 9th, 2003 09:01 AM

Quote:

Originally posted by Tetsuo
On the contrary. The truth is, LimeWire does not work very well for intranets without modifying the source code.
You dont need to modify anything, just add the address pointing at the local adress

Quote:

Last version (2.9.x) moves from 15kb/s outgoing message bandwidth for ultrapeers down to 8kb/s outgoing bandwidth, while improving the search horizon substantially.
If you are a supernod yes, but Limewire does not give me that status inspite the fact that im having ADSL 512/512, so im only leaf. so the 3 hosts have a total bandwidth of 1.5 K only

Quote:

However, to reduce the traffic, LimeWire has limited the number of search results to return.
Ya i know that, also strange, should be much higher.

Quote:

(One problem might be, that if a new LimeWire node connects to a Morpheus/Gnucleus or MyNapster ultrapeer it will return virtually no search results at all, due to the low performance of GnucDNA based ultrapeers).
Both those does not shield off the traffic properly, so i get almost all their traffic here as leaf-nod

trap_jaw2 May 10th, 2003 12:37 AM

Quote:

Originally posted by Sleipner
You dont need to modify anything, just add the address pointing at the local adress
LimeWire will have trouble if that connection ever fails because it will very likely try to obtain new addresses from the public GWebcaches (you can't shut that off in the options). The number of connections an ultrapeer tries to maintain is far too high for a private network.

Quote:

If you are a supernod yes, but Limewire does not give me that status inspite the fact that im having ADSL 512/512, so im only leaf. so the 3 hosts have a total bandwidth of 1.5 K only
That's right.

Quote:

Ya i know that, also strange, should be much higher.
Routing search results is very expensive. - And a total of 150 (or was it 240?) search results is more than enough. I assume it's even better for the network if a user issues more queries instead of getting more results per search because he is forced to be more specific when entering search keywords.

Quote:

Both those does not shield off the traffic properly, so i get almost all their traffic here as leaf-nod
That is strange, GnucDNA based servents usually are using old TTL 7 searches so they are extremely disadvantaged by newer LimeWire ultrapeers. In addition they filter out much more pongs than LimeWire.

When searching with GnucDNA based servents you should not even get a fraction of the results you get from LimeWire ultrapeers - except for terms like mp3.

Sleipner May 10th, 2003 02:29 AM

Quote:

Originally posted by trap_jaw2
LimeWire will have trouble if that connection ever fails because it will very likely try to obtain new addresses from the public GWebcaches (you can't shut that off in the options). The number of connections an ultrapeer tries to maintain is far too high for a private network.
I think it work like this, you manually add a local IP-adress and Port number which not have to be 6345 can be any other, then this adress is set up, Limewire closes connection view window by turning the CONNECTION_VIEW_ENABLED=false instead of true
as it is in .limeprops file. This will stop Limewire from aquire adresses from Gwebcache.




Quote:

Routing search results is very expensive. - And a total of 150 (or was it 240?) search results is more than enough. I assume it's even better for the network if a user issues more queries instead of getting more results per search because he is forced to be more specific when entering search keywords.
However it is, im not satisfied with the search performance of Limewire, it havent change to the better with the new versions here. And again since i mentioned this before I think Limewire have pulled this minimize to the extreme network traffic too far
also due to the fact the majority now sits on broadband not typ 56 k modems any more. So this minimized net traffic profil suites Intranets very well, think about it.

Quote:

That is strange, GnucDNA based servents usually are using old TTL 7 ......When searching with GnucDNA based servents you should
A correction here I meant Mutella and MyNapster, Mutella is worst concerning shield me from this clients traffic the dropped I/0 with 0 drops. Oh! i have an Gnucleus 1.8.4.0 right now status right now is 13 percent, My next host is Limewire latest 2.9.1.0 holds with 93 percent, so you seing the difference here. This also gives a fingerpointing to why Limewire shield of traffic so well, thats before it shall be used in Intranets

trap_jaw2 May 10th, 2003 03:07 AM

Quote:

Originally posted by Sleipner
I think it work like this, you manually add a local IP-adress and Port number which not have to be 6345 can be any other, then this adress is set up, Limewire closes connection view window by turning the CONNECTION_VIEW_ENABLED=false instead of true
as it is in .limeprops file. This will stop Limewire from aquire adresses from Gwebcache.

Setting CONNECTION_VIEW_ENABLED=false just remove the connection window. You won't find the option for not using the GWebCache system without going through the source code. You could add a line to your limewire.props file but that is not documented anywhere.

Quote:

However it is, im not satisfied with the search performance of Limewire, it havent change to the better with the new versions here. And again since i mentioned this before I think Limewire have pulled this minimize to the extreme network traffic too far
also due to the fact the majority now sits on broadband not typ 56 k modems any more.

AFAIK, LimeWire does try to minimize traffic for leafs, it's trying to reduce bandwidth requirements for ultrapeers because that was the networks primary bottleneck.

Quote:

So this minimized net traffic profil suites Intranets very well, think about it.
You don't care about bandwidth consumption that much within a LAN.

Quote:

A correction here I meant Mutella and MyNapster, Mutella is worst concerning shield me from this clients traffic the dropped I/0 with 0 drops. Oh! i have an Gnucleus 1.8.4.0 right now status right now is 13 percent, My next host is Limewire latest 2.9.1.0 holds with 93 percent, so you seing the difference here. This also gives a fingerpointing to why Limewire shield of traffic so well, thats before it shall be used in Intranets
The "dropped I/O" numbers in the connection view can not be interpreted that way. It means how many messages YOU drop, not how many messages the ultrapeer drops that you connected to.
LimeWire ultrapeers send you at least ten times as many Pong messages as Gnucleus ultrapeers for example. Since leafs drop Pong messages ( = they don't relay them to other ultrapeers), they show as dropped messages in that statistic.
That's the only reason LimeWire ultrapeers have such a high "Dropped I/O" value.

gbildson May 17th, 2003 09:52 PM

If you search for something very specific, you will get a much higher horizon then you would have received previously. If you search for a general topic, then a smaller horizon will be used. So, the moral of the story is that you need to know how to search generally - and if you want more results then browse host.

If you want something specific, search for it more exactly. Even after starting a download, this will improve your results for stalled downloaders. They wake up when they get matching results. We just don't automate these requeries because they take up too much bandwidth.


Thanks
-greg


All times are GMT -7. The time now is 01:53 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.