aMule Forum
English => Feature requests => Topic started by: KeRn on August 08, 2005, 12:02:17 PM
-
Hey,
a usefull function for releaser like 'share the needed' would be damn nice in amule. Also 'hide the sources' won't be wrong.
cu
-
and this function what will do? how amule will choose which files needs to be shared? ?(
-
Originally posted by spiorf
and this function what will do? how amule will choose which files needs to be shared? ?(
no - not files but needed part/chunks of a file you've on PS e.g!
-
You mean Hide Overshare? [After uploading a chunk f.e. 3 times it will be hidden to share the other chunks]
And share only the need is similar, but it hides the chunks, which are well distributed.
I don't like this features, because you may think, that the file is incomplete seeing the red bar.
But Selective Chunk Sharing would be a good option. (Usually the client ask for a certain chunk, but with scs the mule selects the chunk to upload to the client.)
-
I don't like any way of disturbing the protocol like that.
-
Imagine how would "
- Download first and last chunk first" work, if all your sources decide to give you some other part instead of what you asked.
-
i think there are two different issues involved:
1) original releaser of a file does not want to be recognizable as the only complete source
to achieve this some emule mods have an option for only reporting single chunks to individual clients and thereby uploading a different chunk to each client. after each chunk has been uploaded 1-3 times, all chunks are revealed.
a byproduct of this feature is that the file is better spread b/c not everybody is downloading the first and last chunk from the releaser.
problems:
- it's much less obvious who the releaser is, but you could still figure this out if you used multiple clients and compared what chunks other clients reported to them
- it's pretty bad if somebody does not know better and turns on this feature for a regularly shared file (b/c chunk x+1 does not get uploaded before chunk x is uploaded, and if chunk x is well distributed but x+1 is not, this would cause big problems)
2) chunks that are rare should be given preference over more common chunks
i think this is actually a pretty good idea. oftentimes you have only very few complete sources and a number of sources that all have the same chunks. when you just started your download there is a good chance that you will download a common chunk from a complete source and not a chunk that you could not have gotten from another source. so in a sense you are wasting your upload slot with the complete source.
giving preference to rare chunks makes a lot of sense, but which chunk to upload should not be the uploaders call to make, b/c this does mess with the protocol and other functions as kry and gonosztopi have pointed out. instead, something like this should be implemented in the downloading client.
so the download priorities would be: first/last chunk (if "download first and last chunk first" is enabled) and then chunks should be downloaded based on how many (better: how few) other clients have the same chunk.
potential problem: this would put more strain on the cpu, which could be problematic for older machines, so it should be an optional feature
-
Originally posted by lionel77
2) chunks that are rare should be given preference over more common chunks
[...]but which chunk to upload should not be the uploaders call to make, b/c this does mess with the protocol and other functions as kry and gonosztopi have pointed out. instead, something like this should be implemented in the downloading client.
[...]
That's actually how it's done now.
-
i didn't realize that. well, "another job well done" i'd say... ;)
-
Originally posted by Kry
Originally posted by lionel77
2) chunks that are rare should be given preference over more common chunks
[...]but which chunk to upload should not be the uploaders call to make, b/c this does mess with the protocol and other functions as kry and gonosztopi have pointed out. instead, something like this should be implemented in the downloading client.
[...]
That's actually how it's done now.
alright; thats ok than and lets forget the 2th question about hidding source :) but it would be good to know that ppl dont know who is the full source.
-
Just curious, why?
-
Originally posted by Kry
Just curious, why?
just imagine; you're releaser and you realase 10 new files (rar/avi/mpg/...) files in a week (sometimes also some hot releases) and we both know that anti-p2p-companies do not sleep. Thats rise a danger imo to be a full source from the beginning.
-
They look for all people with these files. Partially or Full doesn't matter. You have it, you broke their law. Even if the file is a fake, because you wanted this file, and uploaded the parts.
-
Well, it's all your fault for sharing copyrighted material. I wouldn't help anyone trying to hide that fact.
-
Originally posted by Kry
Well, it's all your fault for sharing copyrighted material. I wouldn't help anyone trying to hide that fact.
i didn't talk about myself (we need not to talk about what we'll use ed2k for) ; ok - just forget that one; good to know that 'share the needed' is enabled by default :)
-
I wasn't talking about you either, it was a generic sentence ;)
-
another one question; hows about 'copy feedback to clipboard' for complete files ppl have already in the shared files?