[Rocky18]

Before I get lambasted. I need to know if this is the upload limit built into emule. If it is then it needs to change. If not I would like to know why this happens. You wait and wait and wait then finally connect to a source. And he/she only uploads 9.28 and then goodbye. Now your back to q/slot 2550 from the source you were just downloading from. With the file sizes increasing to 1 gig or more it could take years to download a complete copy. I currently have 3 files with only one complete source each that have been on my screen for a year or more. The limit is way to low....

[Link64]

Yes it is a built in limit. The answer to the question why we need it you probably can figure out yourself if you just imagine how long you would have to wait if all 2550 clients before you would get the entire file instead of 9.28MB.

[Rocky18]

Link I would gladly wait knowing that there would be a second, third or even forth complete source. With emule constantly looking for new sources my chances of conecting to a complete source increase. Thats why I use FAIRPLAY in my MorphXT so I've alway's uploaded at least one complete source of all my files. Maybe that should be added to the basic emule version. It sure as heck is not working this way, over a year and still only 1 source available.

[Link64]

Rocky18, on 17 August 2012 - 12:40 AM, said:

It sure as heck is not working this way, over a year and still only 1 source available.

Yeah, if nobody else wants that file (or unshare it as soon as he has it), what do you expect? No feature can fix that.

[Rocky18]

Link64, on 17 August 2012 - 03:26 AM, said:

Rocky18, on 17 August 2012 - 12:40 AM, said:

It sure as heck is not working this way, over a year and still only 1 source available.

Yeah, if nobody else wants that file (or unshare it as soon as he has it), what do you expect? No feature can fix that.

Link

These are new files. There is still only one complete source available for one simple reason "TIME TO COMPLETE". Most users simply give up and cancel the download out of frustration. For a 928meg file they would need to connect to that source 100 times, each time getting knocked way back in the source que. It may take a month or more to re-connect to get another 9.28 do the math your talking years here. If you can't see that as unacceptable then I don't know what else to say. There has to be some way to prioritize a low source file. I admire the work you guy's have done to create this program. But, if you alway's simply dismiss every suggested improvement as "IT CAN'T BE DONE" or "Why Do We NEED IT" then sadly emule is headed the way of the dinosaur.

[tHeWiZaRdOfDoS]

What you suggest isn't an improvement - quite the contrary - and if YOU don't see THAT, you must be blind.

The current system both ENSURES sharing and SPEEDS UP downloading by preventing ppl to complete and immediately unshare their files and creating new sources ASAP (remember that you can start sharing once you completed a single 9.28MB chunk!).
Yes, it may be tiresome at some points and yes eMule should both improve the upload priority AND the download chunk selection (ICS - rarest part, anyone?) but it should NOT - NEVER EVER - upload a single file to a single user.

[sonoro]

@tHeWiZaRdOfDoS
You say that we should never send complete file to a single person, but it was quite possible and there is unwillingness to do so ..

Assuming that we would have good seeders 100, send all files to complete single source, until she finished all 100 seeders send less upload, and never the complete file to a user because it receives several sources of the same file!


You know that there are many advantages to such requests that user requests, but want to hold a program profile and do not want to evolve into the possibilities which are proposed
I guess no point now asking for resources eMule, he is well built, but it could very well go back to being the most famous p2p, if added some details that deviate the users.

This post has been edited by sonoro: 26 August 2012 - 12:14 AM

[tHeWiZaRdOfDoS]

sonoro, on 26 August 2012 - 02:13 AM, said:

@tHeWiZaRdOfDoS
You say that we should never send complete file to a single person, but it was quite possible and there is unwillingness to do so ..

Assuming that we would have good seeders 100, send all files to complete single source, until she finished all 100 seeders send less upload, and never the complete file to a user because it receives several sources of the same file!


You know that there are many advantages to such requests that user requests, but want to hold a program profile and do not want to evolve into the possibilities which are proposed
I guess no point now asking for resources eMule, he is well built, but it could very well go back to being the most famous p2p, if added some details that deviate the users.

A lot IS possible but doesn't make SENSE - e.g. you could start pushing your car to work instead of driving
For the rest of your text... I simply don't understand it

[Zangune]

Rocky18, on 16 August 2012 - 05:12 PM, said:

he/she only uploads 9.28 and then goodbye. Now your back to q/slot 2550 from the source you were just downloading from

This is not an eMule design weakness, the problem is people that uses eMule.
If I am the only source of a file I set it's priority to release, I unshare common files I own, I give friend slot, I set other files priority to very low.

Rocky18, on 17 August 2012 - 12:40 AM, said:

over a year and still only 1 source available.

When you get a chunck form the original source (A) you become a source, if someone else (B) gets another chunck he/she becomes a source and you can exchange your chunck with B, first source (A) eMule should choose different chunks to send to you and B

Rocky18, on 20 August 2012 - 06:36 PM, said:

There has to be some way to prioritize a low source file

Upload priority. Probably we need more levels of priority than actuals.

Rocky18, on 20 August 2012 - 06:36 PM, said:

if you alway's simply dismiss every suggested improvement as "IT CAN'T BE DONE" or "Why Do We NEED IT" then sadly emule is headed the way of the dinosaur.

People don't understand that things may change, but not surely becomes better because of changes.

[DavidXanatos]

Zangune, on 26 August 2012 - 12:34 PM, said:

]
People don't understand that things may change, but not surely becomes better because of changes.

I think change is always better than no change.
change at least has the possibility of improvement, while no change definitely does not.

If you change something for the worse you can always change back, this way filtering only beneficial changes and overall improving the thing.


Also I agree with the notion that emules upload policy is extremely flawed, and partially responsible for eMules demise in the last half a decade.

Torrent is doing it right, unfortunately it leaks decentrality and keyword search capabilities, but that's changing right now.

[Zangune]

DavidXanatos, on 27 August 2012 - 01:07 PM, said:

I think change is always better than no change.
change at least has the possibility of improvement, while no change definitely does not.

The number of new good ideas should decrease during time, because it grows the possibility that when it comes up a proposal new good idea this was already thought and already dissussed, so I wanted to highlight it should be better to think well about changes this moment on.

DavidXanatos, on 27 August 2012 - 01:07 PM, said:

I agree with the notion that emules upload policy is extremely flawed

As I said before (when Automatc) 3 levels of upload priority could be too few, is this limited number of levels a choice?

[DavidXanatos]

Zangune, on 27 August 2012 - 05:32 PM, said:

The number of new good ideas should decrease during time

I don't think this is generally true, in a static universe that would be, but we live in an ever changing world those what ever was good at a given point in time as time progress gets less an d less and less well suited for the present time.

Important paradigm changed of the last years ware negligently ignored in the eMule development.
I mean things like:
Modern connection speeds, my present day Upload is 8 times faster as in 2002 - 2004 when emule started and head its fastest development.
The legal situation in Germany and other countries.
Emerging cheep and simple embedded platforms I mean imagine an Raspberry PI running an eMule 24/7 attached to a Modern 3 TB HDD that would be the ultimate "Sucker" it does not take much power, uploads and downloads 24/7 and makes almost no noise.

Not look on for example bittorent, they did it right they went with the time, they have an upload policy that grants every user a fast download (no stupid credit system and long waiting queues), and many of the shelf home routers come nowadays already with embedded bittorent clients, you just attach an extern USB HDD and "suck" the Internet dry.
granted needer BT is solving the lagal issues, but that job is being done by the pirate partys independently from technological development.

Quote

As I said before (when Automatc) 3 levels of upload priority could be too few, is this limited number of levels a choice?

I think the amount of priorities is the least of the problems in eMules upload policy.
I think the biggest issue is the overly long waiting queue and credit system, this basically ensures that only the most hardcore users gets decent download speeds, leaving and exploiting all the casual users out there, it simply makes for an elitist system that is not fair towards newcomers.
Also it barrys reare files in a pile of mainstream stuff so that the chances to get something really rear, even theoretically being available are near absolute zero.



David X.

[Zangune]

DavidXanatos, on 27 August 2012 - 11:54 PM, said:

we live in an ever changing world those what ever was good at a given point in time as time progress gets less an d less and less well suited for the present time.

It could be, but you have to proof the new idea is better than the old idea.

DavidXanatos, on 27 August 2012 - 11:54 PM, said:

Modern connection speeds, my present day Upload is 8 times faster as in 2002 - 2004 when emule started and head its fastest development.

And what's the problem with eMule?

DavidXanatos, on 27 August 2012 - 11:54 PM, said:

The legal situation in Germany and other countries.

Illegal trade of copyrigheted stuff should be indipendent from used protocol, shouldn't it?

DavidXanatos, on 27 August 2012 - 11:54 PM, said:

Emerging cheep and simple embedded platforms I mean imagine an Raspberry PI running an eMule 24/7 attached to a Modern 3 TB HDD that would be the ultimate "Sucker" it does not take much power, uploads and downloads 24/7 and makes almost no noise.

eMule has to be rewritten or modified to be Operating System indipendent, is this the proposal? This could be a good idea, but I think it's not one of the developers goals, aMule exists.

DavidXanatos, on 27 August 2012 - 11:54 PM, said:

I think the biggest issue is the overly long waiting queue and credit system, this basically ensures that only the most hardcore users gets decent download speeds, leaving and exploiting all the casual users out there, it simply makes for an elitist system that is not fair towards newcomers.

I don't think so.
Why skilled people are against queue? It's absolutelly incomprehensible to me! Correct me if I'm wrong.
If my upload capacity is not yet full I'll give you a slot, why I shouldn't? You wait because of my bandwidth limitations, not because of my eMule evilness!
From my point of view, when people think credit system can help globally they overestimate credit system network impact. This is questionable.
Removing credit system entirely is an upload killer idea.

DavidXanatos, on 27 August 2012 - 11:54 PM, said:

Also it barrys reare files in a pile of mainstream stuff so that the chances to get something really rear, even theoretically being available are near absolute zero.

We can low credit system impact and tweak priority system, as I said, but this will hurt common files speed.

[DavidXanatos]

Zangune, on 28 August 2012 - 11:29 AM, said:

It could be, but you have to proof the new idea is better than the old idea.

You often cant prove it without trying and not implementing it means not trying it.

Quote

And what's the problem with eMule?

It miss allocates the most available upload so that normal casual users gets sucked instead of being able to download what they want.

Look on Bittorent, it is capable of allowing all users to decently use their downlaod capacity, by allocating upload bandwidth in a reasonable manner.

Quote

Illegal trade of copyrigheted stuff should be indipendent from used protocol, shouldn't it?

Well no, the protocoll could be made anonymising and censorship resistent.

Quote

Why skilled people are against queue? It's absolutelly incomprehensible to me! Correct me if I'm wrong.
If my upload capacity is not yet full I'll give you a slot, why I shouldn't? You wait because of my bandwidth limitations, not because of my eMule evilness!

Well, your queue encorces a first come first serve principle meaning that any newcommer to the sytsem is lassivly disadvantaged at the begining.

Starting uploads randomly would be much more fair and on a logn run for usersthat are online permanentl it would allocate roughly the same amount of upload as with a strict queue, while at the same time being fair to any newcomer.

Quote

Removing credit system entirely is an upload killer idea.

Bittorent works perfectly without it and it has much better speeds than emule, what would suggest, correct me if I'm wrong, that on BT systems more people allocate more upload bandwidth to the client than in emule.

A reason for that is maby, only maybe because the users who can start downloading imminetly when thay want feal fair threaded and want ro return some of the kindness.

While on emule when you start your client you first have to get exploited for some hours by the system befoure you can expect anything in return.


To put it different: a First come first serve queue is only fair if the average waiting time for upload is << average online time of the clients in the queue.
This is not guaranteed by emule, in fact the overly long waiting queue makes for the opposite what simple unfairly benefts users who are online 24/7 over users who are only online for a few hours during the day.

Quote

We can low credit system impact and tweak priority system, as I said, but this will hurt common files speed.

eMules common filespeed couldnt suck more than it already does, theleast one could do is ti make for a decentsped on reare stuff, so that emule keeps at least superiority over bittorent in one aspect of filesharing usage.

David X.

This post has been edited by DavidXanatos: 28 August 2012 - 03:32 PM

[fox88]

DavidXanatos, on 27 August 2012 - 02:07 PM, said:

I think change is always better than no change.

I am sure that cutting your head or limbs off would be definitely a change. Now tell me it's better (always).
Sorry, your generalization skill sucks.

[DavidXanatos]

fox88, on 28 August 2012 - 05:19 PM, said:

DavidXanatos, on 27 August 2012 - 02:07 PM, said:

I think change is always better than no change.

I am sure that cutting your head or limbs off would be definitely a change. Now tell me it's better (always).
Sorry, your generalization skill sucks.

that particular change has already been tryed over and over during the middle ages and failed each time.

We are talking about novel changes here, about trying new stuff.

[fox88]

DavidXanatos, on 28 August 2012 - 07:59 PM, said:

We are talking about novel changes here, about trying new stuff.

If you do not understand that always means 'every time with no excecption', then it would be impossible to explain while your bold statement about random changes is nonsense. Try to learn some basic logic.

Also I do not see why you bring up the old rubbish:
1. credit system kills eMule
2. no credits in torrents (ever heard about ratio?)
3. better upload bandwidth usage in torrents.

All this was discussed too many times in the past; and I just would not explain why your statement are incorrect.

This post has been edited by fox88: 31 August 2012 - 07:28 PM

[DavidXanatos]

Well what did I write exactly "I think change is always better than no change."
This is an statement about changing stuff, it does not mean to do any consiveble change, just to permanently change things.

You seam to have an at least as flawed understanding of English as I do.

Besides even if we take you understanding of my sentence not only to permanently change things but also to do changes without any thinking and do obviously negligent and stupid things.
Thats also better than no change at all, you know how evolution works right?
Completely random changes permanently happening in a population combined with selection lead us here where we are today.
And there ware plenty of changes that left away libs or vital organs, which was allows when they happened selected out and eliminated again only successful changes prevailed
So even such changes as you proposed if they are not the only once are better than no change at all.

What would we be without it, some self replicating molecules without any fancy complexity ...

Quote

1. credit system kills eMule'

ofcause it does.

Quote

2. no credits in torrents (ever heard about ratio?)

Have you ever looked on the source code of an torrent client?
There is no credit system there is a session long scoring and tit for tat mechanism.
The data usually are storred on a per file basis and not between sessions.
It is nothing like emules persisten credit system.

Quote

3. better upload bandwidth usage in torrents.

Obviously as you see on the superior performance of bittorent clients.

David X.

[Zangune]

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

You often cant prove it without trying and not implementing it means not trying it.

Why not? This is Logic duty.

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

It miss allocates the most available upload so that normal casual users gets sucked instead of being able to download what they want.

Sorry, I can't understand. Can you explain me why upload bandwidth growing during years is not well supported by eMule please?

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

Well no, the protocoll could be made anonymising and censorship resistent.

OK, it's technically possible but

Unknown1, on 20 July 2003 - 06:01 PM, said:

Anonymous network also always suffer from a huge waste of bandwidth (> 50%) which is needed to guarantee anonymity

It's a performance killer, it's unacceptable for large and noob filled peer to peer comunity.

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

Starting uploads randomly would be much more fair

Randomly!?

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

on a logn run for usersthat are online permanentl it would allocate roughly the same amount of upload as with a strict queue

That's impossible! If now I get 10 and the system rewards me because of my patience I would get 5 if system didn't rewad me, I think it's obvious.

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

Bittorent works perfectly without it and it has much better speeds than emule, what would suggest, correct me if I'm wrong, that on BT systems more people allocate more upload bandwidth to the client than in emule.

I think we (I?) have to investigate about that because your deduction is the easiest, but I can't see any rational reason to this.
Seedboxes?

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

A reason for that is maby, only maybe because the users who can start downloading imminetly when thay want feal fair threaded and want ro return some of the kindness.

No, this not. Upload starts immediatelly unless the client has no shared files, this should happen just the first eMule installation time.

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

While on emule when you start your client you first have to get exploited for some hours by the system befoure you can expect anything in return.

So? Again: it's a bandwidth problem, not eMule evilness.

DavidXanatos, on 28 August 2012 - 05:23 PM, said:

To put it different: a First come first serve queue is only fair if the average waiting time for upload is << average online time of the clients in the queue.
This is not guaranteed by emule, in fact the overly long waiting queue makes for the opposite what simple unfairly benefts users who are online 24/7 over users who are only online for a few hours during the day.

We have a different conception of fairness.

I'm really bored about torrent discussions.
If clients upload capacity is filled how to distribute download bandwidth is a matter of choice, not superiority of one method upon another method.

[DavidXanatos]

Zangune, on 28 August 2012 - 09:15 PM, said:

Why not? This is Logic duty.

Well many things have so many variables and possibly unforseen machanisms that you simply can not simmulate them effectively.

Or why do you think scientists are still making experiments?

Quote

Sorry, I can't understand. Can you explain me why upload bandwidth growing during years is not well supported by eMule please?

eMule locks in bandwidth resources to alitist users that run their clients 24/7 screwing over all causal users.
Thats leads to many users leaving the network, it might have been remotely reasonable in times where uplaod bandwidth was an extremly reare comodety like 10 years ago.
But for modern connections this elitist behavioure ist plain wrong.

Quote

Anonymous network also always suffer from a huge waste of bandwidth (> 50%) which is needed to guarantee anonymity

That is wrong,
granted if you demand that every packet will be routed at least once than you would be right.
What you practically need is not anonymity but deniability.

So for example a system where lets say 10% peers set thair packets to be routed at least once, while 90% leaves the default setting of 0 hoops. And a design that makes packets relayed for some one else indistinguishable form packets send by one self.
Here you have only a very small additional network overhead and those only a small performance degradation, but you can not make anyone responsible for anything because you can not prove in any way that the packets you received form him really originated by him and ware not merely relayed for some one else.

Quote

That's impossible! If now I get 10 and the system rewards me because of my patience I would get 5 if system didn't rewad me, I think it's obvious.

What do you mean?

Look, if the average waiting time is 3 hours, and you had your client run for considerably longer than that, you will get upload roughly the same amount of times with a random queue as with an fifo queue.

Thats the whole point, thats basic statistics.

Quote

No, this not. Upload starts immediatelly unless the client has no shared files, this should happen just the first eMule installation time.

we are talking about different things.

I mean that while others start immidetly suckung you dry, you dont get anything form the system (except you found an other sucker that just started up his client).

Usully with emule you will always have to wait for some time befoure you will recive any downlaod dorm others.

And thats bad!

Quote

So? Again: it's a bandwidth problem, not eMule evilness.

No its emules evilness, a random queue would make sure you would start first downlaods much more quickly.



If you have a fifo queue if you start up your client you will always at the first hours as long as your Up time is < average queue waiting time dont get much download you will be exploited for the benefit of those who are online 24/7 thats not fair.


With a random queue you will get the same amount of download / hour you would get running your client 24/7 ofcause I'm talking here about the queue system of the other clients not once own.

There is no fair reason why any newcommer should be allowed to be exploited by the system as long as his up time is not >> average remote queue waiting time.

Quote

We have a different conception of fairness.

why?