Outline · Standard · [ Linear+ ] Urgent Update, Blacklist Handling

Please,
as the new lungdum server is out it is very urgent to have a fix on they "crazy" behavieur

Something like:
as only for the first 25 files (the ones that miss less bytes to complete)

once a file is completed add another one


Or something like:
add in paused mode.
automaticaly remove pause mode from the "first" 25
when download finishes start another one.


It's crazy... but...
if you can release a 1g.2 it should be great.


Max

in preferences there is a possibillity to start new downloads on pause and to continue paused download when a file completes.

Is that what you are asking for?

JB

I'd like to add some more advanced functionalities like:
- maximum number of active files
it means automaticaly, before a connect to a server is done, the file queue is checked and if there are more than the "maximum..." files active some are put in waiting
- unpause precedence
to be able to check to uncheck before the file nearer to be completed, or the rarest, or via grouping (i.e. all the files that have quite the same name Max 1, Max 2 etc... if none available go on on the next fiel)

and things like that.


Thanks,
max

I think the question is related to the new server software functionality that 'blacklists' you if you are doing certain things (like sharing more than a couple of files!).
mfsav2 is requesting the server software has a few more smarts to pause some files if you are perhaps sharing too many.etc.
Problem is as I understand it the paused files also get counted. They woud have to be 'stopped' to not figure in the 'shared' file count. The partially downloaded files is just as guilty as a share as the complete shared file.

Well there's actually two issues. Both the number of files you are sharing and the number of files you are downloading. The server keeps track of both. Simply pausing files so you're actively downloading less than 30 should keep you from being penalized for having too many downloads but you will still need to manually unshare some files if you are sharing too many.

QUOTE (MrCC @ Aug 10 2003, 09:01 PM)

I think the question is related to the new server software functionality that 'blacklists' you if you are doing certain things (like sharing more than a couple of files!). mfsav2 is requesting the server software has a few more smarts to pause some files if you are perhaps sharing too many.etc. Problem is as I understand it the paused files also get counted. They woud have to be 'stopped' to not figure in the 'shared' file count. The partially downloaded files is just as guilty as a share as the complete shared file.

Paused files are sent as shared files as long as they have a full chunk but are not sent for sources.

A shared file only spends 2 server credits, a lookup for sources for one file spends 17 server credits.

Unless you have A LOT of shared files, the problem are the downloads.

Well on the faq about blacklisting of Silent Bob is explicity declared that the shared files DOES NOT count for the "blacklist" points.

On the other side I've found some servers that reject me (not blacklist, only reject) becouse "too many sharing".

The point is: is a P2P network ???
the objective should be to have people sharing it's contents in order to spread diffusion and speed up distributio.

If I have to remove shares... well take off the queuing mechanims too !!! how to I get precedente if I cannot share files ????

I don't know your point of viewo but there is something strange about all this stuff.... that could lead ed2k to death.


Mf

Oohhh, I'm not happy to hear this.

<rant>Sounds to me like this is a bug in both the server software and the client software since they don't work properly together. The clients aren't efficient enough in making server requests and the servers aren't intelligent about handling it-- they just kick you off with an uninformative message that makes it sound like it's your fault. Blacklisting people like me who share lots of files and have good upload bandwith isn't going to help the network at all. My download speeds have gone way down in the last couple of weeks and it's more difficult to find sources. I tweaked around with the Files and Connection settings and it's a little better now (thanks to source exchange) but I can't get on to any of the main servers anymore. If reducing the number of shared files is the only solution, that bodes poorly for the whole network. eMule is just too slow to only be downloading a few files at a time, epecially on a cable internet connection. </rant>

My question is: does it help to reduce the number of connections or increase the time interval in the Connections -> Max Connections setting, or will that only make it worse, i.e. is totally seperate from server requets? If not is there any way at all to control how eMule makes requests to the servers? I already have "Safe Connect" on.

QUOTE (inertia1200 @ Aug 14 2003, 04:23 PM)

Oohhh, I'm not happy to hear this. <rant>Sounds to me like this is a bug in both the server software and the client software since they don't work properly together. The clients aren't efficient enough in making server requests and the servers aren't intelligent about handling it-- they just kick you off with an uninformative message that makes it sound like it's your fault. Blacklisting people like me who share lots of files and have good upload bandwith isn't going to help the network at all. My download speeds have gone way down in the last couple of weeks and it's more difficult to find sources. I tweaked around with the Files and Connection settings and it's a little better now (thanks to source exchange) but I can't get on to any of the main servers anymore. If reducing the number of shared files is the only solution, that bodes poorly for the whole network. eMule is just too slow to only be downloading a few files at a time, epecially on a cable internet connection. </rant> My question is: does it help to reduce the number of connections or increase the time interval in the Connections -> Max Connections setting, or will that only make it worse, i.e. is totally seperate from server requets? If not is there any way at all to control how eMule makes requests to the servers? I already have "Safe Connect" on.

Actually, blacklisting was already in place for some time; only you didnt get kicked, just stopped receiving new sources from the server. However, since clients also trade sources with one another, this was somewhat compensated.

Also, according to tests made by the server maintainners, too many files arent good for the network; dont ask me why

As for any of the other solutions you ask, i believe none work, only some modifications on the clients themselves (and those will only bring more complaints).

It seems though that a new server is in the works that will change the way the requests are done and eliminate these problems.

too many files cause strains on the network....so this can't be good for edonkey/emule, neither is sharing fewer files.

QUOTE (Blacklord @ Aug 14 2003, 10:54 PM)

It seems though that a new server is in the works that will change the way the requests are done and eliminate these problems.

The new server is a total rewrite by lug, he plans to use Gzip compression when we talk to servers. Sending your fileshashs to the server will take less bandwidth so the servers will allow you to send more files by giving you a higher Server credit rating for using Gzip compression.

Alot of what lug has done aimed at saving bandwidth and blocking clients that use too much bandwidth.

This post has been edited by moosetea: Aug 14 2003, 23:27

Is Gzip anyway similar to Zip files?

Kind of (G stands for Gnu), its opensource. Emule currently uses Gzip compression when we do client->client transfers. The data that is sent to and from servers should compress well as its mainly text

This post has been edited by moosetea: Aug 14 2003, 23:31

well i hope it produces less overheads and improves the network greatly

QUOTE (moosetea @ Aug 14 2003, 11:26 PM)

The new server is a total rewrite by lug, he plans to use Gzip compression when we talk to servers.  Sending your fileshashs to the server will take less bandwidth so the servers will allow you to send more files by giving you a higher Server credit rating for using Gzip compression.

That's good to know that the developers are working on this. I guess we just have to be patient while the kinks get worked out. In the meantime I guess I'll just try using different servers and pausing some downloads. Other than this problem eMule Plus has been working great for me.