[WentloogWhix]

In order for a feature to be accepted/rejected, what is the preferred process?

1. Do I need a poll?
2. Is there a "panel of judges"?

How do I know what the verdict is? How long does it take?

[Andu]

The devs decide and either they are so kind as to tell you they will implement something or you'll be pleasantly surprised when a version is released.

[OlegatorFromMule]

The mule badly download, but well distributes.
I use the mule since 2000. And if developers used it that it would know. But, it can be corrected easily if add the button that the user could to specify itself quantity of people on download. The speed download less than people, the more to everyone. Because, the mule gives all all Internet and everyone receives on 3-5кb/s still it is possible to add the button the faster download the less return. And on a turn the more return the is less download. In the rest the mule suits me

This post has been edited by OlegatorFromMule: 01 February 2010 - 02:51 PM

[yegle]

Any progresses on these features?Are they still the status the last time it was edited?

[Some Support]

Well the status really only changes on releases for already listed features, so no news here. As i have posted in other threads already, it is however a pretty good guess that the hash resistance improvement will make it into the next version.

[Flore_Bv_Ro]

Hi. Somebody know, if the next new emule version, in future, is posible to have support and for others networks, please ( for exemple torrents ).
Regards.

[omeringen]

Flore_Bv_Ro, on 10 April 2010 - 05:04 AM, said:

Hi. Somebody know, if the next new emule version, in future, is posible to have support and for others networks, please ( for exemple torrents ).
Regards.

Read the first post please. . .

[xilolee]

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

Features you won't see in eMule:
[...]

• Support for [any P2P-Network] - there will be no support for additional networks. We will concentrate our work to improve the Ed2K and Kad protocol. Also more networks means more overhead.

[...]

[Flore_Bv_Ro]

xilolee, on 10 April 2010 - 04:08 AM, said:

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

Features you won't see in eMule:
[...]

• Support for [any P2P-Network] - there will be no support for additional networks. We will concentrate our work to improve the Ed2K and Kad protocol. Also more networks means more overhead.

[...]

To bad. Ok, no problem. thx

[torpon]

He already knew the answer

Flore_Bv_Ro, on 07 April 2010 - 05:29 AM, said:

Hola tengo una pregunta
Van a sacar alguna version de emule con la posibilidad de descargar y ficheros torrent, algun dia ?
Me gusta el emule y lo e utilizado mas de 4 años, pero como no se puede descargar y torent prefiero el lphant v 3.51, de momento.
seria perfecto si lohaceis para ambas cosas, algo parecido con flashget, lphant, etc
gracias

torpon, on 07 April 2010 - 08:12 AM, said:

En la parte inglesa del foro puede leerse esto:

Quote

Features you won't see in eMule:
...
Support for [any P2P-Network] - there will be no support for additional networks. We will concentrate our work to improve the Ed2K and Kad protocol. Also more networks means more overhead.

Por si no dominas el ingles
Funciones que no veras en eMule:
...
Soporte para otros [P2P-Redes] - No habra soporete para redes adicionales. Concentraremos nuestro trabajo en mejorar los protocolos Ed2K y Kad. Mas redes significan también mas sobrecarga.

Saludos

This post has been edited by torpon: 10 April 2010 - 02:31 PM

[Semm]

Regarding the ongoing requests in changing eMule into a so called "anonymous network" I would like to point out that this wouldn't just result in technical but also in severe legal problems (at least in Germany).

Yesterday the German Federal High Court of Justice ruled, that citizens are liable for their internet-connection in case they don't take measurements to prevent unknown persons to abuse their internet-connection for copyright infringements. Otherwise they have to pay fees to the media companies' lawyers on behalf of the "unknown infringer". Therefore in an anonymous routing network innocent German eMule users would have to pay the fines for the copyright infringements of others!

see: Institute of European Media Law - Germany: BGH Finds WLAN Operator Liable

edit: link added

This post has been edited by Semm: 28 November 2013 - 06:10 PM

[CondorcetVotingIsBest]

Either the description of SUQWT is so misleading that it caused eMule's developers to oppose SUQWT, or SUQWT would not fix the problem that motivated it and should be opposed (in which case a different feature, SRUQ, see below, should be supported).

The problem it is meant to fix is that when a client exits, it resets its upload queue when it is re-launched, which means it forgets all the old upload requests' wait times. (I presume that for efficiency the queue actually holds arrival times, not wait times; wait time can be calculated when needed by subtracting arrival time from current time.) This behavior tends to make rare files--rare parts of files, to be more precise--effectively unavailable when the client that is their sole source frequently exits. (In my opinion, it is a bug when a client forgets its own upload queue.)

The proper fix is for each client to save its own upload queue when exiting, and then restore the queue when re-launched. To disambiguate, let's call this feature (bug fix) "Save and Restore Upload Queue" (SRUQ).

The description of SUQWT, however, gives the impression that the queue positions to be saved are the positions of the exiting client in other clients' upload queues (requiring some form of communication to all those other clients). This won't fix the problem caused by the source going offline frequently.

So I ask eMule's developers to reconsider SUQWT as if the requested feature was really SRUQ.

Also, I ask eMule's developers to take a closer look at the issue of rare files downloading extremely slowly. Since the philosophy of eMule appears to favor file availability (multiple sources, in other words) over transfer speed, boosting the upload of rare files (or rare parts of files) would make eMule's behavior more consistent with its philosophy. I think this could be handled effectively by simply adjusting the credit formula to greatly boost the uploading of files for which the uploading client is the only complete source, or perhaps by automatically setting files' upload priority to "Auto: Release" when the client is the only complete source (instead of "Auto: High"). Or perhaps some mechanism for discovering extremely slow uploads could be implemented, and upon discovery the file's upload would be boosted.

Regards and thanks!

[Stulle]

no, you just need to learn how eMule works, that's pretty sufficient. just a hint, there isn't actually anything like a queue rank... the queue rank is just a generic number that we derive from sorting all clients by their score. the score, in turn, is calculated based upon file priority (saved), up/down ratio (saved) and waiting time (not saved in official). so everything that is required for ensuring that people don't loose their queue rank is actually ensuring they don't loose their waiting time because - like i said - the QR actually means nothing at all.

and another hint for free today, because i am in a lovely mood in this sunny weather: don't be wise with people on your first post.

(somebody split this, please.)

[Link64]

CondorcetVotingIsBest, on 20 Juli 2010 - 04:45 , said:

The proper fix is for each client to save its own upload queue when exiting, and then restore the queue when re-launched. To disambiguate, let's call this feature (bug fix) "Save and Restore Upload Queue" (SRUQ).

Saving and restoring the queue is pretty pointless, because:
- the clients in the queue have probably got a new IPs, so you can't find them, when you want to upload something to them
- if you share rare files, specially if you are the only source, you have to republish them in Kad, the ones who like to have them must find that, and all that take for sure longer, than the half to 1 hour they have left to contact you before they are out from the queue.

It might work for very short eMule break, for example if you need to reboot the system, but still SQUWT is the better way to do it.

[CondorcetVotingIsBest]

Link64, on 20 July 2010 - 03:36 PM, said:

CondorcetVotingIsBest, on 20 Juli 2010 - 04:45 , said:

The proper fix is for each client to save its own upload queue when exiting, and then restore the queue when re-launched. To disambiguate, let's call this feature (bug fix) "Save and Restore Upload Queue" (SRUQ).

Saving and restoring the queue is pretty pointless, because:
- the clients in the queue have probably got a new IPs, so you can't find them, when you want to upload something to them
- if you share rare files, specially if you are the only source, you have to republish them in Kad, the ones who like to have them must find that, and all that take for sure longer, than the half to 1 hour they have left to contact you before they are out from the queue.

It might work for very short eMule break, for example if you need to reboot the system, but still SUQWT is the better way to do it.

Link64,

Regarding your point about IP addresses changing: First, according to the online eMule documentation, every client has a unique permanent hash number which is used to identify them. I assume the upload queue stores the hash number of each client waiting to download, along with the arrival time of each client's request. If the source client saves its upload queue when exiting, and restores the queue when it is re-launched, this would allow the source client to use the restored waiting time when the client with that unique hash number asks again for the file. I don't see why a changed IP address would interfere.

Second, why do you say the source client would be unable to find the clients trying to download (if their IP addresses changed)? Doesn't the finding go in the other direction? Don't the clients trying to download find the source client, when they periodically ask the source for a file part? Doesn't the requesting client provide both its identifying hash number and current IP address to the source client each time it asks?

Third, assuming you're right that a changed IP address somehow makes a queued client hard to find, wouldn't it be hard to find regardless of whether the source client stayed online or went offline for awhile? A changed IP address does not seem to cause a problem when the source stays online; doesn't this imply changed IP addresses will not be a problem, period?

Your next point is a bit hard to parse, but let me see if I've understood your words... you seem to be saying that if the source client exits, a client who was trying to download from it using Kad will not regain its position in the source client's queue if the source stays disconnected for a long time (more than an hour or so). I assume you mean you think SRUQ won't fix that. The only way that makes sense to me is if the source client purges from its (restored) queue any request from a client that hasn't asked recently. If that's what you mean, I'd like to know the basis for that claim, since if you're right about that, I'd suggest modifying the SRUQ proposal so the purge from the queue is delayed long enough after the queue is restored to give Kad clients enough time to find the source again. (Also, even if you're right that SRUQ would not help with Kad, you'd also need to be right about it not helping with ed2k to claim it's pointless.)

Your final claim that SRUQ might help only when an eMule client goes offline for a short time is even harder to parse, since you didn't specify which client--the source or the downloader--is the one that goes offline. Whatever... that point didn't attempt to provide any explanation.

I've already established by experiment that my eMule client does not lose its place in other clients' upload queues when I go offline for a short time. (Even if it did lose its place, eMule's developers have indicated they wouldn't want to mitigate harm a downloader does to himself by going offline, since they want to maintain incentives to stay online all the time.)

The description of SUQWT correctly identifies the problem is caused when the source client (for a rare file) goes offline, but its proposed solution specifies behavior triggered only when a client trying to download (the rare file) goes offline. (Citing the webpage that defines SUQWT: "SUQWT saves each upload queue client's wait time when it exits the upload queue and restore it the next time the client comes back in the queue.") This means SUQWT, the way it's written, wouldn't solve the problem. How would you suggest rewriting it so it would?

[CondorcetVotingIsBest]

Stulle, on 20 July 2010 - 11:19 AM, said:

no, you just need to learn how eMule works, that's pretty sufficient. just a hint, there isn't actually anything like a queue rank... the queue rank is just a generic number that we derive from sorting all clients by their score. the score, in turn, is calculated based upon file priority (saved), up/down ratio (saved) and waiting time (not saved in official). so everything that is required for ensuring that people don't loose their queue rank is actually ensuring they don't loose their waiting time because - like i said - the QR actually means nothing at all.

and another hint for free today, because i am in a lovely mood in this sunny weather: don't be wise with people on your first post.

(somebody split this, please.)

Stulle, my post didn't mention queue rank. Why did yours?

[Andu]

First of all this is not a discussion thread. Second how is SRUQ a FAF? As far as I can tell there is 1 thread about it and even there I don't see all that many people being in favour of it.

Maybe my logic is flawed though.

[Stulle]

recreating the upload queue is pointless because it would mean recreating upload ranks at a given point in time. beside the fact that this is highly not FAF and should be split (see my first post or Andu's post) you have to realize that the queue is a one way thing. requesting clients will have to decide if they want to ask us for anything or not. it's not the source's job to figure out who is still out there waiting for data. it's called source for a reason. sources offer, they don't push anyone to take anything.

summing it up, SUQWT is all you need if you want to ensure nobody loses anything he earned himself up until now, including upload queue waiting time.

you should learn how the protocol and the various clients work before you try requesting anything like this. especially suggesting that a client should "sign off" another clients upload queue is just ridiculous. it is ridiculous because what happens if a client just does not sign off? our queue blows up and we have hundreds of unsuccessful upload session. not too smart, is it now?! so just quit it already, no matter how lengthy your explanations and badly constructed scenarios will be, you won't make a point. ever. at least not in this field. because rewriting the entire protocol is neither good nor desirable in the way you suggest.

[guapy3]

Hello!!!
Maybe it's not the place to ask this, so I apologise in advance. But I have a doubt. I have emule v1.2e in my laptop pc (I think, something like that, I can't check 'cos my laptop doesn't work by now) and I could select in "Security" my antivirus in order to check all downloads immediately once they finished. However, I downloaded the last version of emule (v0.50a) in my desktop pc and I can't find where to indicate the direction to the antivirus and check finished downloads. Will someone indicate me? Thank you!

[SS1900]

1) yes this is the wrong section.

2) v1.2e ? ...it means emule plus...it isn't an official emule and so no support here for it ...so you should install the official emule before to ask us somethig.

3) the right section was this > http://forum.emule-p...hp?showforum=40

4) here you can find the official emule > http://sourceforge.n...es/eMule/0.50a/