A Tech Question
Re: A Tech Question
I have a question which I hope is still on same topic. Why, on a KAD dearch do you NEVER get complete sources confirmed on any file over a very moderate size (usually about 5MB). All that is ever returned by these searches is a question mark in this field ?
Thanks
Thanks
-
Guest
Re: A Tech Question
interesting question - I never had any success with searching
Re: A Tech Question
Notice that the "official recommendation" was written in 2005. The server situation is radically different now, there are 10% as many good ones and 10 times as many fakes because the anti-P2P agencies see attacking servers and creating fakes as a simple way to hurt eMule.idler wrote:Nope. Of course, you only need a few servers, but you should have a choice. Normally, you sort your servers for the number of users or the number of files and chose one of the top. To filter the ip of fake servers, you insert a "filter.dat" into your security settings; you can update it, for example, here:ghost wrote:No!! disable these features! You will get a lot of fake and unsecure servers!!
You only need about 5 good servers. Update your server.met from http://peerates.net/servers.php
http://emulepawcio.sourceforge.net/nieu ... filter.zip
As for the settings for updating servers, here the official recommendation of eMule-project:
http://www.emule-project.net/home/perl/ ... pic_id=130
Remember than it matters not only what server you are connected to, but also what other servers are active in your server list. The server you are connected to gets the lion's share of eMule's attention asking for file sources, but not all of it. Every so often (half hour? don't recall) eMule asks one unconnected server in your list if it has sources for your downloads. It cycles though all unconnected servers this way one at a time. So the more fake servers the longer it will take you to find sources. But you should have as many good servers as you can get so you will see someone sharing the file even if they are connected to a different server.
The number is actually 9.28MB. This is the size of one chunk of eMule data. KAD doesn't track completeness, it would cause too much traffic it's a distributed system which doesn't have thousands of continuous connections like an eMule server. So any file needing more than one 9.28MB chunk is unknown. But since eMule won't share a file for downloading unless there is at least one complete chunk, if the file is shorter than that it must be complete so it is listed as such.plonkah wrote:I have a question which I hope is still on same topic. Why, on a KAD dearch do you NEVER get complete sources confirmed on any file over a very moderate size (usually about 5MB). All that is ever returned by these searches is a question mark in this field ?\
Re: A Tech Question
Thank you for the technical explanation - it IS important to know how the technology you are using actually works. So from what you have said, there is no way (yet) in KAD to know if all of the other chunks exist in complete state without actually starting a download and seeing the dreaded "last seen completed - never". Also by checking the stats by hovering over the download link - is that correct ?FLL wrote:idler wrote:ghost wrote:No!! disable these features! You will get a lot of fake and
The number is actually 9.28MB. This is the size of one chunk of eMule data. KAD doesn't track completeness, it would cause too much traffic it's a distributed system which doesn't have thousands of continuous connections like an eMule server. So any file needing more than one 9.28MB chunk is unknown. But since eMule won't share a file for downloading unless there is at least one complete chunk, if the file is shorter than that it must be complete so it is listed as such.
One final point, yesterday, a new server appeared (I think in Maurice list of trusted servers ?) - Australia P2P Research Server. I am not doing anything remotely illegal, but this is one country I would not trust with data across a wire. What is your feeling - delete this server for good ?
Thanks again for the succinct reply.