Thread: About Limewire
View Single Post
  #6 (permalink)  
Old May 10th, 2003
trap_jaw2 trap_jaw2 is offline
Disciple
 
Join Date: May 10th, 2003
Posts: 11
trap_jaw2 is flying high
Default

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.
Reply With Quote