eMule 0.22c Plus 4 - Vorlost.1i [21.02.03] *BETA3* Anticrash

[vorlost]

eMule 0.22c Plus 4 - Vorlost.1i(beta-3)
------------------------------------------------
can be downloaded here:

binary:
ed2k://|file|eMule.0.22c.Plus.4.-.Vorlost-1i-binary(beta-3).rar|663921|a2b6d444750a99fd3ff25efc3973d29f|/
http://www.emuleitor.com/downloads/Vorlost...t-1i-binary(beta-3).rar

source:
ed2k://|file|eMule.0.22c.Plus.4.-.Vorlost-1i-source(beta-3).rar|1064247|7f72a461f27033f937f3b332e31b1da7|/
http://www.emuleitor.com/downloads/Vorlost...t-1i-source(beta-3).rar
----------------------------------------------------------------------------------

Falls es Probleme mit dem MOD beim starten gibt, löscht bitte im Temp Ordner alle Dateien die KEINE .part oder .part.met Endung haben (Dateien wie z.b. .src .stsrc .prio)


eMule 0.22c Plus 4 - Vorlost.1h
---------------------------------------
can be downloaded here:

binary:
ed2k://|file|eMule.0.22c.Plus.4.-.Vorlost-1h-binary.rar|647674|f929bb5edbe3113e90dfe27a76e65154 |/
http://www.emuleitor.com/downloads/Vorlost...t-1h-binary.rar

source:
ed2k://|file|eMule.0.22c.Plus.4.-.Vorlost-1h-source.rar|1111132|07402210cd8ddf2172efd6de26e57b1 c|/
http://www.emuleitor.com/downloads/Vorlost...t-1h-source.rar

21.Feb.03(Vorlost.1i ->BETA-3 !!!<-)
=======
Graphics:
- New Splashscreen Logo[Pink Frog]

Statistics:
- Codeupdate to 0.23b.1, Statistics are now updating automatically
- Codeupdate otherfunctions(used by statistics) from 16.11.02 -> 13.12.02

Anticrash/Fake:
- There are new mlDonkey´s out there which send corrupt "Hello-Packet´s" in order to
crash eMule(invalid Username), but i discovered that they try to crash eMule with
invalid port-numbers too or try to disable communication with eMule sending us
a different clientport.
- We just ignore these crashers and don´t add them as possible clients anymore
(to avoid further attacks)
- fixed: Found another download-packet(empty ?) that leads to a crash
- changed faked Port-Range from 23-10000 to 23-65535 other ports show crash-message

UAP(Upload Auto Priority)[Tarod]:
- feature: Auto-Disable UAP(UploadAutoPriority[Tarod]) when a file is Paused[Vorlost]
Resuming that file reactivates UAP if previously set.
- updated: UAP-Code to eMule0.25b - Tarod.16d
(Tarod changed high-priority from <200 sources to <1000 !!!, seems to be a wrong modifier
RARE_FILE(=40)*25=1000 instead of RARE_FILE*2.5)...
- changed: Now Release-Priority(<20 Sources) will be given too if the min. availability
of a partchunk is <= 10, High-Priority(<50 Sources) or availability <= 25
UAP assigns Release & High only if at least 1 needed partchunk is available.
- changed: Now the PartFilePrio is only saved when needed[vorlost]
-> creating a new file, updating priority manually with the menu
With this the Priority ´normal´ from Auto-Disable-UAP is no longer saved to hd.
After a restart of eMule and resuming a paused file -> the previously set-priority
will be restored.
- removed: code was present twice, now my modification should really work...

Movie Preview Mode:
- Is now named File Preview Mode
- bug fixed(uncritical) in "Load rarest finished chunks - Patch2" -> V2.1 now FilePreview
only needs overall >5 same parts to enable Loading Of Preview-Partchunks, was sometimes
randomly 10.
- features: Preview-Modes allowed for Sound & Archive[Vorlost]
- features: from 0.25b ArchiveRecovery added[Barry],
show corrupt Archive-Entrys too[Vorlost] -> Preferences/Files
- added: VLC-Support (completely untested)
[build in Preview Code(Movie,Sound) is diabled, only moviepreview via VLC is possible !!!]
(This Part will be rewritten because only always the 2 first & 2 last partchunks were been
taken to build a preview-file, CPU goes 100% if file is shorter than 2 partchunks,
other downloaded blocks/parts ignored)

Preferences:
- fixed: Preferences source-income Log-checkboxes doesn´t load their setting from prefsfile,
LogTCP-Sources:already known sources are assigned to this switch too
- changed: DataRate is max.4000 allowed with UploadThrottle(uses autom. higher upload if
possible)
- updated: Directories to 0.24b-5b Code
- Log Anticrash-Attacks(code improved) & BanShield(code improved)
- Allow Multiple Instances of eMule(nearly all code added, some changes in prefs missing,
but maybe it could work a little bit)
- Verbose: Added More Information about LoadingBlocks & MovieParts,
WrongPartNumber will only be displayed with Verbose enabled now...
- See my share: Is now available for Friends too
- Disable SlowMovingUploadSources(AntiLeech) for all or just Friends is ready
- raised: The Upload-queuesize to 10.000 !!!

Updates toward 0.25b:
- update: from 0.25b > CPartFile:eleteFile() added other file extentions that should
be deleted when a file will be removed: .movie, .stats
- update: to 0.25b-code Preview[but disabled, much changes to do here...]

SlowMovingUploadSources:
- changed: variable init of SlowMovingUploadSources changed(works the same as before)
- can be disabled for Friends or for all in the Preferences(disables all AntiLeech-Features)

HoldingUploadClients:
- The min. Uploadtime of 10 Minutes is disabled for SlowMovingUploadSources
(Friends will now always be holded this 10 Minutes.)
- We have now a Friend-Slot, this Friend will be holded max. 1.5hours in the Uploadslots
(only the Friend with the most score will be holded if more than 1 is present)

LoadedSources:
- changed [Loaded Sources] will be loaded until MaxSourcePerFileSoft is reached instead of
MaxSourcesPerFile, so we have more room for [Exchanged Sources] left.

ClientDetailDialog:
- Show Friends, Show SlowMovingUploadSource, Show Client´s place in our Uploadqueue
- Show both Version-Informations( Network[eDonkey]/eMule )
- Show masked mlDonkey´s: <ClientSoft: mlDonkey(emule)>

Other:
- fixed: Clicking on an ed2k-link opened another eMule
- fixed: When we run low on hd some files will be paused but we still receive data
for this file -> results in a lot of beeps/messages and tries to save on already full hd.
- feature: show masked mlDonkey´s(or non eMule´s) in grey color again
in the upload & download window
- updated: mlDonkey detection code, Banshield works much better now

07.Feb.03(Vorlost.1h)
=======
Upload-Slots:
- Jeder Upload dauert jetzt mindestens 10 Minuten, die Haltemeldung welche bei einem Upload kleiner 5Minuten kam ist somit nicht mehr aktiv...

Preferences:
- 2 min. Uploadslots erlaubt
- Einige Grundeinstellungen verbessert(wenn man den MOD ohne Preferences neu startet[braucht man aber nicht ! - ist nur für Neulinge])Ich habe noch einige Meldungen eingebaut damit man sieht warum einige Einstellungen nicht akzeptiert werde.
- Nun darf man mehr als 3000 bei der Datenrate einstellen wenn man weniger als 4 MinUpClients eingestellt hat. Allerdings sollte man beim Gebrauch von UploadThrottle die Datenrate niemals über 4000 einstellen(Upload wird zeitweise sehr unregelmäßig, sprich zu niedrig).
- Übernehmen(Apply) in den Preferences bewirkt nun eine sofortige Änderung der Zahlen(falls diese nicht akzeptiert werden) für die Preferences Advanced und Connection.
- In diesem MOD kann man verfolgen von wo wir Quellen wann und wieviele brauchbare bekommen, wen es stört oder nur einige sehen will kann diese jetzt einzeln abschalten -> Preferences/Generals für [Loaded Sources],
[Exchanged Sources], [Server Sources-TCP], [Server Sources-UDP]
Letztere werden aber noch nicht angezeigt, kommt bei der Umstellung des Server-codes...
- ein/abschalten von Verbose Meldungen(Spezielle Meldungen fürs Debugging, wird normaler Weise nicht benötigt kann aber bei der Fehlersuche sehr behilflich sein und Ihr könnt diese endlich abschalten , das Laden der Movie-chunks kann z.B. hierbei überprüft werden)

ClientDetailDialog:
- Die ScoreRatio im Client-Detail Fenster benutzt nun Zahlen mit 2 Stellen hinter dem Komma.
Wer wissen möchte wie viel Score sich bei eine Quelle für euch angesammelt hat kann diesen nun auch ablesen unter Score-Ratio(our own). Dieser Eintrag stimmt natürlich nur dann wenn diese Quelle nicht zwischenzeitlich die clients.met gelöscht hat und somit eure Scores futsch sind. d.h. die eigene Score wird aus den Werten der eigenen Clients.met errechnet.

07.Feb.03(Vorlost.1g)
=======
- Added: RemoveNoNeededPartsSources[Tarod 25b-16d], aber diese werden nur durch neue Quellen die über [Exchanged Sources](da diese meist gültig sind und somit schneller abgearbeitet werden können) empfangen wurden ersetzt wenn die max.Anzahl an erlaubten Quellen erreicht wurde[Vorlost]
- Bugfix: Normally only the first 100 received sources from a client are allowed to be
added to a file, now we allow 100 sources that could be really added[Vorlost]
(doesn´t maked so much sense only to allow nearly the same first 100 sources every time
to be added as new sources because they could be useless the 2nd time)
- Added: Remove LowtoLowIP-Sources when 80% of max.sources per file are reached[Tarod]
- Resized: Startup Splash-Screen Font
- Removed: "Resetting SearchTime" - Message
- Changed: Filereasktime again
NoNeededParts -> 144min. Filereasktime (if >2/3 of max. Sockets are in use)
- Added: mlDonkey is now shown in ClientDetail-Dialog too.[Maverick]
Changed: mlDonkey recognition for upload/download/client-detail-window,
an mlDonkey which uses features from eMule or tries to mask as an eMule doesn´t look like
an eMule anymore and got his grey color back, the clientsoft is named different in
this case -> example: "mlDonkey(eMule)" instead of "eMule".[Vorlost]
- Feature: mlDonkey Banshield[Vorlost] idea by [Maverick]
(Maverick wrote about newest mlDonkey-code:
It basically means all clients that have a queue size > 1000 are banned
and all those with queue size > 500 have a smaller score.)
mlDonkeys are still able to reiceive their place in our queue but only receive a
down or upscaled range from 1-500 no matter if we allow less or more than 500 sources
max. queue-size. - New Message when this happens...
- Feature: The source income of [Loaded Sources],[Exchanged Sources] and
[Main-Server Sources] show how much of them could be added as new sources.[Vorlost]
- If a source sends us 0.0-0.4 kB/s it won´t get the additional download-score for uploading
until the source sends at least 0.5 kB/s.
Some Leechers try to earn more score with this behavior.
And there´s a patch from zz out there that uses "trickle"-standby slots before they
change to full upload-slots.

07.Feb.03(Vorlost.1g)
=======
- Added: RemoveNoNeededPartsSources[Tarod 25b-16d], but NoNeededPartsSources will only be
removed for each new source if max.sources per file is reached[Vorlost]
- Bugfix: Normally only the first 100 received sources from a client are allowed to be
added to a file, now we allow 100 sources that could be really added[Vorlost]
(doesn´t maked so much sense only to allow nearly the same first 100 sources every time
to be added as new sources because they could be useless the 2nd time)
- Added: Remove LowtoLowIP-Sources when 80% of max.sources per file are reached[Tarod]
- Resized: Startup Splash-Screen Font
- Removed: "Resetting SearchTime" - Message
- Changed: Filereasktime again
NoNeededParts -> 144min. Filereasktime (if >2/3 of max. Sockets are in use)
- Added: mlDonkey is now shown in ClientDetail-Dialog too.[Maverick]
Changed: mlDonkey recognition for upload/download/client-detail-window,
an mlDonkey which uses features from eMule or tries to mask as an eMule doesn´t look like
an eMule anymore and got his grey color back, the clientsoft is named different in
this case -> example: "mlDonkey(eMule)" instead of "eMule".[Vorlost]
- Feature: mlDonkey Banshield[Vorlost] idea by [Maverick]
(Maverick wrote about newest mlDonkey-code:
It basically means all clients that have a queue size > 1000 are banned
and all those with queue size > 500 have a smaller score.)
mlDonkeys are still able to reiceive their place in our queue but only receive a
down or upscaled range from 1-500 no matter if we allow less or more than 500 sources
max. queue-size. - New Message when this happens...
- Feature: The source income of [Loaded Sources],[Exchanged Sources] and
[Main-Server Sources] show how much of them could be added as new sources.[Vorlost]
- If a source sends us 0.0-0.4 kB/s it won´t get the additional download-score for uploading
until the source sends at least 0.5 kB/s.
Some Leechers try to earn more score with this behavior.
And there´s a patch from zz out there that uses "trickle"-standby slots before they
change to full upload-slots.

27.Jan.03(Vorlost.1f)
=======
- Changed: Filereasktimes:
QR-Place present -> 36min. Filereasktime (if >2/3 of max. Sockets are in use)
QR-Place >250 -> 45min. Filereasktime (if >2/3 of max. Sockets are in use)
NoNeededParts -> 126min. Filereasktime (if >2/3 of max. Sockets are in use)

- Features from 0.24b-5b:
- Prevent double downloadclients[Lord KiRon]
- Low-ID fix in CListenSocket::OnAccept
- ML-Donkey Emulation for ML-Donkeys[Maverick] (unchangeable to eDonkey-behavior)
- SPOOF bug fix by [moosetea]

25.Jan.03(Vorlost.1e)
=======
- Feature: Added "Movie Preview Mode" - Menu[DonGato] in order to enable the new
changeable moviemode feature in "Load rarest finished chunks first - Patch2"[vorlost]

"Load first/last Movie chunks first" in the preferences is acting as a main-switch for
all files in order to disable the MoviePreview for all files together (if you spend your
time at the weekend somewhere else or you are on holiday).
The MoviePreview-Menu is disabled when you disable "Load first/last..." in the Preferences
in order to show you that you disabled MoviePreview for all files.
The choosen MoviePreview-Modes are still present for each file if you reenable
"Load first/last..." in the preferences.
What does the 1F and 1L thing mean in the MoviePreview-Menu ?
2F: It means that 2 parts(chunks) will be loaded first from the beginning of a file
1L: It means that 1 part(chunk) will be loaded first from the end of a file

21.Jan.03(Vorlost.1d)
=======
- Changed: Lowered the expanded Filereasktime to 45min. for Queueranks >500
(in order to not loose positions in the downloadqueues)
We loose our place in an uploadqueue if we don´t reask for a file latest after 60minutes.
So 2 Vorlost.1d eMule won´t have that problem anymore.
- Show when we loose a place in an downloadqueue
- Feature: FastReaskMode - After about 55min. (5min. before we could be kicked out of
an uploadqueue) only clients where we have a place in a queue (QR-Value shown) are
reasked in order to continue moving through the uploadqueue.
This Feature will be used when about 2000-sources or more are found for all files together.
- doubled the clear dead clients value in order to keep still alive clients in our
uploadqueue(most eMules are not fast enough to reask for a file every 60minutes).
- Fixed a bug in "Load rarest finished chunks - Patch2": The message which block in which
part is currently downloading took too much CPU-Power.

KnownBug:
=========
Sometimes the message when loosing a place in an downloadqueue might be wrong...
- The message is wrong when we download from another Vorlost.1d eMule and less than
120minutes passed by because this MOD allows now a filereasktime of 120minutes
instead of 60minutes.
- All messages that show that FastReask starts after about 55Minutes... is always correct,
but sometimes clients want to know their QUEUE-position very late(after hours...):
i don´t know what these clients do exactly before in order to leads to this false message
that we loose a place in a queue.
We only loose our queue-place when we have a place in a queue
and we reask the next time after 60minutes.
Things i have done yet to prevent this false message:
I have set our place in the queue to 0 when this happens:
- if the source has suddenly NoNeededParts(because we downloaded it somewhere else)
- we downloaded the last available block from a client -> has now NoNeededParts too
- the download timed out(the source leaves the net)
- the moment the source starts to send us the file(we begin to download)
in order to prevent the false loosing message.
- When we receive a queue-ranking if we don´t asked for it the LastAskedTime will be set
in order to reset the Filereasktime to 0-minutes.

02.Jan.03(Vorlost.1c)
=======
- Bugfix in SlowMovingSources
Only Normal,Low,Very-Low Filepriorities were changed but too much...
(Wrong Filepriority detection variables corrected...)


27.Dez.02(Vorlost 1b)
=======
- LoadRarestFinishedChunks Patch2
The last part(chunk) of a file will not be loaded first at priority(No movie files)
(It was loaded first because it was nearly always the one that was most complete)
Now the last part will be handled as any other normal part
- fixed a bug in patch2(PreviewAvailable) when trying to preview.
- Preview is available when at least about 1MB is loaded at the start&end of a file.
- FileEndings can now be lower/upper/mixed-case... in order to detect a movie

- In the Download-Window we see now yellow-clients too.

- SlowMovingSources, the FilePriorities of Clients which have already
max. DL/UP-Modifier=10 for us will be converted from Release > Low or Low > VeryLow

- HoldingUploadClients
Upload Clients will be hold 5min. longer if they should be kicked before uploaded 5mins.
YellowClients will be hold upto 1.5hours in the uploadqueue:
The half of the uploads-slots(round up) are reserved for holding YellowClients.
YellowClients with less DL/UL-Modifier will be replaced by clients with
a higher Modifier(at least 5-10 min. uploads)
Uploadclients where we have reached our max.DL/UL-Modifier will be handled as before.
Important Uploadclients can still enter the uploadqueue every
5minutes(for Short,Rare,Release,High-Priority Files).

- fixed a crash when a server is sending an serverinfo that makes eMule crash.

- fixed a crash directly after start of eMule when we try to unfold the first sources
of a file.

- changed the command AddLogLine in the complete source to enable another bool parameter
in order to enable/disable some notifiers(for devs only)

- eMule is now able to handle much more sources of a file
The waitingtime of "NoNeededParts" is normally twice the normal waiting time.(18.3min * 2)
If 3/4 of the sockets(open connections) > are used the time will be doubled a second time.
If we already own a place in the Downloadqueue(QR > 0) of a client the client will be
reasked where we stay now in the queue after 18.3 * 2 minutes(doubled time) when 3/4 of
the sockets are open.
If we own a place in an downloadqueue > 500 the Filereasktime will be doubled again
18.3min. * 4 but only again if 3/4 of the sockets are in use...
This saves a lot of Bandwith to other sources because a lot of them will be
asked again later than normal= every 18.3 minutes and we have a very low count of
"Too many connections" after a while.

max.connections in 5 secs. try 35(i use this) or less(>20)... in order to have this effect.

20.Dez.02 (Vorlost 1a)
=======

- Both Lugdunum p65 patches for manually & automatic server-connect added !!!

- Fast Reloading Stored Sources - All sources will be loaded and reloaded.
max.connections in 5 secs. try 35(i use this) now or less(>20)...

- changed the command AddLogLine in the complete source to enable another bool parameter
in order to enable/disable some notifiers(for devs only)

- SlowMoving Uploadsources

- Stop Listening on Clientport-Fix by Dnowo

- ServerDisconnectBug fix by xrmb

- RarestFinishedChunks Patch2(Movie) without an rightclickmenu for every File yet...
Conifigured to this:
Finish chunks when more than 10 same chunks are present(instead of loading rare ones)
Load 1First&1Last Moviechunk first when more than 5 same rare chunks could be taken.
(If it does make no difference to rareness -> moviechunks will be loaded earlier
when not more than 5 same rare chunks are available.)
Disabling "Load First/Last Moviechunks" in the prefs loads moviechunks without any priority,
but could be loaded randomly because they are calculated as normal chunks or when the source
only got moviechunks...
- Moviepreview status in the box down/left on rightclick(enough free space for preview,
how much is missing for preview
- Moviepreview is available when 1/4First & 1/4Last chunk is available.
(in order to preview very early: the 1 or 2 last chunks are loaded BACKWARDS !!!)
(the last 1 or 2 chunks are now always loaded backwards)

- Now we can see how much sources each Server sends to us...

(some debug text enabled) now you can see how some things work...

Example:
12/06/02 22:09:12: Reloading all sources for ............
This means that the sources for this file will now be reloaded from the beginning...

12/06/02 22:09:12: New source No. 1 added for ............
Here you see when LoadedSources are loading their sources...

Upto 40 sources were loaded for every file(slow-loading sources) again and again until all
sources are loaded.
20 Sockets will be left open. The next 40 loaded-sources will be loaded when
opensockets<maxsockets-40-20.

error-text from serverconnections are all displayed

Loading Blockx/52 FW from Part 22/30 in Filename
This means that Block xx of total 52 Blocks from Part(=chunk) 22 from total 30 chunks
is loading for Filename now. FW=Forward BW=Backward (LoadRarestFinishedChunksFirstPatch2)

Known Bugs in the latest Release:
=================================
- eMule crashed 2 times now in 2 weeks while closing(after saving stored sources).
21.02.03: not happend again yet
- The Statistics - Average Upload & Download is not shown correctly.
A crash was reported by PinkFrog when entering the statistics window on WinME.
- Sometimes there could appear a wrong "We loose our place in a queue..." message.
- Jigle FakeCheck is crashing on my pc if i call it from the rightclick menu of a
Download-File(never reported by a user)
- eMule never crashed yet if we just leave it work alone for a very long time...
(sorry this is not a bug it´s a feature )

Next things to do:
==================
- Update/Debug Statistics Code.
- Add [Tarod 25b-16d] feature to show the exact mod-name of a source in the download
and client-detail window. Maybe later in the statistics too for every MOD that supports
this feature.
- Update the Server-communication code
- Support UDP for Sources -> Change Mod-Version from 0.22c to 0.23


Vorlost
Danke an Dr.Slump für den Mirror!
Inoffizielle Vorlost Homepage: http://pinkfrog.iespana.es/ oder http://de.internations.net/pinkfrog/

[Cul8er]

Hi Vorlost,


01/25/03 20:38:33: This amount of sockets is open now:449 and new will be opened now
01/25/03 20:38:33: TooManySockets = false
01/25/03 20:38:34: This amount of sockets is open now:450 and new will be opened now
01/25/03 20:38:34: TooManySockets = false
01/25/03 20:38:35: This amount of sockets is open now:451 and new will be opened now
01/25/03 20:38:35: TooManySockets = false
01/25/03 20:38:36: This amount of sockets is open now:452 and new will be opened now
01/25/03 20:38:36: TooManySockets = false
..................................

CPU Usage 100%

What's wrong here?

Using WinXP Pro - ADSL

Cul8er

[Usul]

Diese Fehlermeldung hatte ich bei der 1d in solchen Massen, das mir nach 1-2 Stunden das Logfile auf 4 GB Größe angeschwollen ist -> Absturz des Mods. (Dateien unter Windows können nun mal nur 4 GB groß werden, ich schätze, das Mod fängt das nicht ab.)

[Pink_Frog]

ich glaube das problem ist bekannt und wird in der nächsten verion nicht mehr vorhanden sein...

[vorlost]

Nun da bei mir diese Meldung gar nicht kommt(es ist keine Fehlermeldung !!!) hatte ich wohl vergessen diese zu entfernen, sorry...
Wird zur nächsten Version entfernt.

Vorlost...

[vorlost]

Zitat von Usul

Diese Fehlermeldung hatte ich bei der 1d in solchen Massen, das mir nach 1-2 Stunden das Logfile auf 4 GB Größe angeschwollen ist -> Absturz des Mods. (Dateien unter Windows können nun mal nur 4 GB groß werden, ich schätze, das Mod fängt das nicht ab.)

Ich glaube deine max. connections in 5 Sekunden sind zu hoch, versuch mal 35(für DSL).

Nun wie dem auch sei die Meldung habe ich entfernt,

1f ist fertich... mit ein bischen Code von der 0.24b-5b eMule Plus:

Die Filereasktime habe ich nochmals verändert um noch mehr Quellen ansprechen zu können:

Die Quelle ist neu oder wir haben keinen Platz in der Warteschlange:
Normale Filereasktime von 18Minuten.
Hat diese Quelle einen Platz in einer Warteschlange Platz 1-250 so verdoppelt sich die Filereasktime auf 36min. wenn 3/4 der max. Leitungen(max. connections[bei mir 450]) erreicht sind.
Bei einem Platz in der Warteschlange > 250 beträgt die Zeit 45minuten, der eMule hat jetzt noch 10Minuten Zeit eine Verbindung aufzubauen.
Schafft er das nicht wird bei 55min. der Fastreaskmode aktiviert der dafür sorg das nur noch Clients welche einen Platz in einer Warteschlange haben bearbeitet werden.

Dann gibt es ja auch noch die "NoNeededParts"-Clients,
diese werden nicht wie normal nach 36min. erneut gefragt ob sie nun etwas haben, sondern erst nach 126min. also ~2h (7-Fache Filereasktime, normal 2Fach[1e-Version 4-Fach]).
Durch diese gesparten Anfragen werden neue Quellen gefragt bzw. alte ob nun ein Platz in der Warteschlange frei ist.

Neuer Code von der eMule0.24b-5b:

- von [Lord KiRon] um doppelte Quellen bei den Download-Dateien zu verhindern.
- ML-Donkey Emulation damit der eMule so tut als sei er ein ML-Donkey für ML-Donkeys(haben wohl Einschränkung für eMule wie z.B. nur 1 Upload zu max. 1 eMule zur Zeit) ist.Die Einstellungen ob eMule sich für eDonkey oder ML-Donkey ausgiebt ganz frech wech gelassen.
- Nun dabei habe ich noch Code gefunden der "Low-ID´s zu Servern" verhindern soll.
- Und einen SPOOF bug fix von [moosetea](keine Ahnung was der so genau macht).

Vorlost...

[Relict]

Ich hoffe nur das auch die CPU-Belastung niedriger geworden ist, nicht wie die 24b Plus-Version oder Deiner vorigen 1e (wahrscheinlich wegen der Debug-views).
da ist es Katastrophal.

Es gibt auch noch User mit weniger CPU-Power. Und die kommen meiner Meinung nach seit der 21-er Reihe zu kurz.

Ich z.B. habe ein Dual-PII 450Mhz System. Was ansonsten ziemlich flott ist und so manchen 1GhZ noch aussticht. Doch bei EmulePlus Versions schläft es nach längerer Nutzung ein und wird sau träge, was leider auch dem Download schadet.

Ansonsten bin ich ein Fan Deiner Features. Top.

[vorlost]

@Relict,

ich habe gesehen das Tarod das SourceExchange nicht generell immer zulässt, weiterhin nimmt die CPU-Belastung erst durch viele Sources stark zu.

Ich nehme deshalb an das es Hauptsächlich daran liegt das der Esel zu häufig seine Quellen weitergeben soll.

Solange nicht mehr als 1 Message pro Sekunde ins Log geschrieben wird sollte die CPU-Belastung auch kein Problem sein.

Kann sein das die CPU-Belastung bei 0.25-Clients wesentlich besser abläuft, kann ich aber hier nicht so richtig nachvollziehen da ich selbst 870Mhz zur Verfügung habe.(Sieht so aus als würden einige Funktionen nun im Hintergrund ablaufen)

Weiterhin kann ich wohl auch nicht alle features übernehmen die es so gibt, da sie mittlerweile doch zu umfangreich geworden sind...und andere Programmteile jeweils auch mit verändern...

Vielleicht gibt es ja mal eine offizielle Version die nicht ständig abstürzt guten upload/download hat...
Allerdings ist die 0.25 schon derart umgeschrieben worden das es schon recht schwierig wird bestehende Patches daran anzupassen.
Es wird einfach zu heikel nicht alle kleinen Änderungen an Variablen oder anderen Stellen im Code im Auge zu behalten.

So wie es aussieht werden andere Coder wohl auch wieder aus bequemlichkeit auf die schlechtere offizielle "Load finished-rarest chunks first" routine umsteigen(Wegen der zu großen Änderungen an der 0.25 von den offiziellen Entwicklern").

Auch schade das die offiziellen Entwickler so einfach unsere Ideen von uns Codern in schlechterer Weise nachbauen und es für ihre eigene Idee ausgeben.
bzw. unsere Patches immer noch nicht integriert haben.

Aber das liegt natürlich auch daran das jeder eine eigene Meinung darüber hat wie ein MOD zu funktionieren hat...

[vorlost]

Ich würde zu gerne Wissen welche Features Ihr an meinem MOD liebt und warum und natürlich was stört

Das sind die Sachen die ich mir als nächstes vornehme:

-"Resetting Search Time..." Meldung raus
-automatisch die SourceExchange-Anfragen(eingehende, sowie abgehende) einschränken[Tarod]
-low to low-id clients entfernen wenn 80% der max.Quellen einer Datei erreicht sind[Tarod]
-Eine NoNeededParts-Quelle löschen sobald die max. Anzahl Quellen erreicht ist und eine neue dazu kommen könnte.[Vorlost]
-UDP Kommunikation senden/empfangen für Anfragen von/nach für quellen -> 0.23(umbenennung des Mods in diese Version)
-Aktuellen Serverkommunications & Anzeige - code(fürs Log) übernehmen.

-dann vielleicht endlich: update des "Statisik Fensters", update der "Statistik" um automatisch zu aktualisieren, und später evtl. den kompletten code für die Statistiken.

-VideoLanClient für Datei-Vorschau
-.rar,.zip, usw./MP3-Vorschau
-Lade seltensten vollständigsten Part zuerst(Load rarest finished chunks first - Patch3)


Alles in allem wird das dann wohl ein Mod 0.22c(Plus4)-024b(Plus 5b) / 0.25b(Tarod 16d) der sich dann als 0.23 zu erkennen geben wird

Sprich liegt irgendwie dazwischen...

[Relict]

@vorlost

Also Deine Top Features sind die filereasktime und alles was damit verbunden ist.

Ich denke auch, das bei den PlusMods die Statistiken wie Baum und Diagramm zuviel CPU-Power kosten. Habe die mal testweise auf "aus" gestellt und siehe da es geht merklich so ca. 20% runter mit der Belastung. Beim automat. Quellenaustausch ausschalten auch, nur ist das nicht zu empfehlen. Nur kurz nach dem Start des Muli, bis er so genügend Quellen gefunden hat.

>>"Solange nicht mehr als 1 Message pro Sekunde ins Log geschrieben wird sollte die CPU-Belastung auch kein Problem sein. "

Vielleicht könntest Du mit Abschaltung der ständigen Anzeige von den Anfragen im Serverfenster (z.b. 40 new sources for file ... added) die CPU-Power noch weiter drücken?

Ich frage mich sowieso, wieso die PlusVersionen wesentlich mehr Ressourcen und CPU brauchen als die anderen oder originalen?
An den zusätzlichen Funktionen kanns ja wohl net unbedingt nur liegen.
Höchstens an deren Effizienz und Codeoptimierung.

Aber mal was anderes: Da ich ja ein Dual System s.o. habe, könnte man dann nicht die neue Version mit mehr Prozessor-Threads kompilieren?

Vergleich von Multi-Threading. Beim Multi-Threading wird die Last einer Anwendung auf mehrere CPUs aufgeteilt.

(http://www.de.tomshardware.com/cpu/2...ges/multi1.gif)


Und für PII Systeme eine spezielle MMX Version, da dort ja noch kein SEE etc. integriert ist? Oder eine Automatikfunktion, die den Prozessor irgendwie automatisch erkennt und sich sich darauf einstellt.

Ansonsten freue ich mich schon auf Deine neue "23-er".
Super.

[vorlost]

Zitat von Relict

Vielleicht könntest Du mit Abschaltung der ständigen Anzeige von den Anfragen im Serverfenster (z.b. 40 new sources for file ... added) die CPU-Power noch weiter drücken?

Das könnte man sicherlich, aber so oft kommt diese Meldung nicht, ich brauche diese Meldung um zu sehen ob "Loading Stored-Sources" auch immer schön funktioniert... bzw. wann die Quellen gerade erneut geladen werden.(Nun durch diese Meldung ist mir zumindest aufgefallen das die MOD-Entwickler irgendwann mal einen Fehler gemacht hatten der verhindert hat das die gespeicherten Quellen vollständig geladen werden. - Ist jetzt in den Plus-Versionen durch mich korrigiert. )

Zitat von Relict

Ich frage mich sowieso, wieso die PlusVersionen wesentlich mehr Ressourcen und CPU brauchen als die anderen oder originalen?
An den zusätzlichen Funktionen kanns ja wohl net unbedingt nur liegen.

Jede neue Funktion braucht etwas CPU-Power.

Zitat von Relict

Höchstens an deren Effizienz und Codeoptimierung.

Das auch...
Die Benutzeroberfläche ist wohl auch etwas umfangreicher.
Wer weis wie manche Sachen optimiert werden können kann mir den Code zuschicken.

Zitat von Relict

Aber mal was anderes: Da ich ja ein Dual System s.o. habe, könnte man dann nicht die neue Version mit mehr Prozessor-Threads kompilieren?

Die 0.25 & aktuellere Plus-Versionen arbeiten mit neuem optimierten code der zusätzliche Threads nutzt.

Zitat von Relict

Vergleich von Multi-Threading. Beim Multi-Threading wird die Last einer Anwendung auf mehrere CPUs aufgeteilt.

Ich könnte mich irren aber die unterschiedlichen eMule Bereiche sollten jeweils in einem anderen Thread laufen. Kenne mich mit Multi-Treading noch nicht aus.
Was mir auffällt ist das wenn ich gleichzeitig eine CD brenne(16x) die CPU-Belastung durch eMule ansteigt, warum eigentlich ?!?

Zitat von Relict

Und für PII Systeme eine spezielle MMX Version, da dort ja noch kein SEE etc. integriert ist? Oder eine Automatikfunktion, die den Prozessor irgendwie automatisch erkennt und sich sich darauf einstellt.

Für jede der Patches 10-Verschiedene Versionen coden die auf dem jeweiligen Prozessor besser laufen ? Da würden wir bei dieser Vielfalt regelrecht mit neuen bugs um uns schmeißen. Nene ich denke das sollte die Aufgabe des Compilers bleiben. Im code habe ich solche Lösungen die jeweils den Prozessor abfragen bisher nicht gesehen.

Im offiziellen engl. eMule-Forum ist irgend jemand der MOD´s unterschiedlich für einzelne Prozessoren auf Anfrage compiliert. Das macht aber nicht so viel Sinn da eh ständig neue MOD´s heraus kommen und diese angepassten MOD´s zu schnell veraltet sind. Weiterhin weis er auch nicht mehr so genau wie er diesen Compiler eingestellt hat, bzw. wollte das keinem mitteilen.

Zitat von Relict

Ansonsten freue ich mich schon auf Deine neue "23-er".

Super.

Im Moment wieder weniger Zeit zum coden, kommt alles so nach und nach...
Ja was mir noch wichtig ist wird die Unterstützung der .backup Dateien sein, unter NT hatte ich dann doch 3 mal Datenverlust da ich unbedingt ein instabiles Tool benutzen wollte/mußte(immer diese Bana-Soft )

Vorlost...

[DivisionbyZero]

Hi Vorlost,

Ein Kompliment erstmal für Deine neue f-Version ... die verbraucht bei mir bei weitem weniger Resourcen ... und der Webserver funzt nun auch (bei der e-Version ging er nicht - wieso auch immer)

Habe aber mal 2 Fragen dazu:

1. Ich habe viele Downloads komplett auf rot stehen ... unter den Details steht dann [zu viele Verbindungen] ... ist das ein Fehler bei meinen Einstellungen oder bei den anderen?

2. Bei den Statistiken steht bei mir keine durchschnittliche Downloadrate ... unter der Anzeige "durchschnittliche Uploadrate" steht nur ein "Warte..." ... (ich denke mal, da soll die Downloadrate stehen - die taucht aber nie bei mir auf ...

Habe einen P200 mit WinME ... max. Verbindungen auf 400 gestellt (Testweise) ... max gefundene Quellen auf 100 (Test)

Danke im Voraus

Divi

[vorlost]

@DivisionbyZero:

Zu 1)
Zunächst müßte ich wissen wie viele Quellen Du für diese Datei hast und für alle zusammen.
Zu den Einstellungen bei DSL 768/128 oder 1536/256 empfehle ich unter Preferences/Connection/max.Connections "450 In 5 sec.35"
Falls Deine Hardware es verkraftet kannst Du auch diese 450 höher einstellen, evtl. wird es dann auch noch notwendig den 2.Wert dahinter die 35 weiter zu erhöhen da ansonsten diese Anzahl an Verbindungen NIE erreicht wird(Im Statistikfenster beobachten).
Zu "zu vielen Verbindungen": lassen sich leider nicht vermeiden da nicht jede Quelle sofort abgefragt werden kann(aber wie gesagt falls es bei Dir geht mal höhere Werte probieren). Je höher diese Werte allerdings sind je mehr Upload geht für reine Anfragen drauf.
Dieser MOD fragt nicht so häufig die Quellen erneut ab(normal ca. alle 18min., quellen mit bisher keiner uns fehlenden Stelle(part/chunk)alle 36minuten.
Dadurch das jetzt die Quellen erneut viel später abgefragt werden(WENN mindesten 2/3 der verfügbaren Connections ständig in Gebrauch sind) werden statt dessen andere bisher nicht gefragte Quellen bearbeitet -> mehr Quellen bei denen wir dann in der Warteschleife stehen.
Der Effekt ist natürlich nur dann da wenn 2/3 der Connections ständig in Gebrauch stehen und die erste Wiederanfrage einer bereits gefragten Quelle ansteht, also nach 18Minuten.

Weiterhin funktioniert dieser MOD so das er neue Quellen nicht sofort abruft, sondern es wird eine zufallige Wartezeit generiert die dafür sorgen soll das alle Dateien gleichmäßig Ihre neuen Quellen abfragen - das ist dafür gut das z.B. bei mehreren Dateien die ersten Anfragen an Quellen nicht nur haupsächlich erst mal an eine Datei gehen sondern an alle.
Vorher war es so das eMule die Dateien von oben nach unten nach Quellen abgefragt hat d.h. die oben in der Liste stehen waren zuerst dunkelblau allerdings wurden vereinzelt von den unteren Dateien auch schon quellen geprüft aber halt nicht gleichmäßig(extrem wenig). Das hatte dazu geführt das die letzteren Dateien schon mit einem Download begonnen haben(2 von 200 Quellen abgefragt) und dann natürlich nicht unbedingt die seltenen Stellen zuerst geladen wurden. Jetzt sollte es so aussehen das alle Dateien etwa gleichmäßig nach Quellen gefragt werden.

Wenn eine Datei auch nach 18Minuten noch Komplett auf rot steht deutet das darauf hin das Deine Quellen nicht über die Dir noch fehlenden Stellen verfügen, bzw. zu wenig Quellen verfügbar sind.
Es kann auch sein das diese Datei gerade erst von 1 Person ´released´wird aber noch niemand direkt zu dieser Quelle Kontakt hat, sprich keiner hat auch nur ein Stückchen der Datei.
Je mehr Quellen sich am Download einer Datei beteiligen je höher ist auch die Warscheinlichkeit das einer bei der Einzigen Quelle etwas herunter laden kann.
Leider gibt es immer wieder User die einzelne Dateien bei sich unter "Shared Files" auf "Very Low" stellen was dazu führt das jeder weit mehr als 10h in der Warteschlange warten muß.
Wenn dann der Esel dieser Quelle nach 8h abstürzt oder neu gestartet wird hat man evtl. das Glück am Anfang der Warteliste zu stehen oder gar nicht durch die Warteschlange durch kommt.
"Very Low" entspricht so in etwa gar nicht rausgeben und "Low" nach 10h.....was natürlich auch wieder davon abhängt wie viele sich für diese eine Datei interessieren.

2)
Du solltest den Esel so lange an lassen bis Du sowohl einen Download als auch einen Upload hattest ansonsten kann die Statistik nicht arbeiten.
Gehe dann auf die Statistik-Seite warte 10Sekunden und klicke 1* auf den vertikalen Slider mit dem Du den Inhalt der linken Seite nach oben/unten verschieben kannst.
Nur dadurch wird das Statisik-Fenster aktualisiert !!! Ich weis iss ätzend war aber schon vorher bei dieser Plus-Version so(gehe später dabei das zu korrigieren und updaten).
Nun kannst Du alle 5 sec. wieder den Slider anklicken um die Statistiken links zu aktualisieren, die Grafiken auf der rechten Seiten laufen ja ohne Probs.

Ein P200 könnte zu langsam sein viele Quellen abzufragen.
Auf einem P500 kann man nebenbei auch schon nicht mehr viel machen allerdings läuft der Esel dann.
Ich haben einen P800 auf 870 laufen da kann man dann noch nebenbei surfen und 16x brennen.

Ich würde zunächst erst mal beobachten ob dein Esel es überhaupt schafft diese Anzahl an Verbindungen zu öffnen. ca.max. 18Minuten abwarten, normaler Weise sollten diese 300 von Deinen 400 Verbindungen schon nach ca.2 Minuten erreicht sein.
Am besten eine Grafik der Statistik posten.
Leider habe ich noch keine Erfahrung mit einem P200 gemacht, sollte aber definitiv zu langsam sein. Da hilft nur viel rumprobieren mit den Einstellungen.
evtl. die "max. sources per file" reduzieren -> spart CPU oder eine neuere Version von mir abwarten in der ich Tarod´s Beahndlung von "Exchanged Sources" übernommen habe.
Ich glaube das diese Funktion bei einer großen Anzahl gefragter Quellen zu viel Upload und CPU schluckt..
Jede Quelle die wir wenn auch nur 1* anfragen fragt uns regelmäßig alle 18Minuten wo Sie bei uns in der Warteschlage steht(Vorlost´s MOD spätestens nach 45Minuten-> falls die Anfrage nach55Minuten dann noch nicht dran kam geht der "Fast ReastMode[tm] by Vorlost" an um vor Ablauf der max. Abfragezeit von 60Minuten die Stelle in der Warteschleife zu behalten.(Ansonsten verlieren wir diesen, machen alle anderen MOD so ohne eine Fehlermeldung raus zu geben) -> im FastReaskMode werden nur noch Quellen abgefragt welche einen Platz in einer Warteschlange haben(QR-Wert).
Je mehr Quellen wir einmalig anfragen egal ob wir diese Quelle danach löschen oder nicht fragt uns alle 18Minuten nach Ihrem Platz in der Warteschlange und evtl. auch noch nach "Exchanged Sources". Jede Anfrage einer Quelle von außen führt wiederum dazu das wir diese als Quelle übernehmen(Deshalb bisher keine "Drop NoNeededSources" Funktion).

Bei der nächsten Version wird die Filereasktime für "NoNeedeParts" von 7 auf 8-Fach weiter erhöht.


Vorlost.

[DivisionbyZero]

@Vorlost
... ist ziemlich harter Tobak für mich, da ich mich bis jetzt mit der Technik, die hinter mule steckt, nicht so beschäftigt hatte ... ich bin aber dabei, mich darin einzuarbeiten.


Da meine Hardware nun wirklich ziemlich düftig ist, habe ich getestet, mit welchen Einstellungen sie noch einigermassen läuft ... unter max. Connection stehen jetzt "400 In 5 Sekunden 60" (trotz Windows ME wo man ja nicht so viel einstellen soll) ... damit hängt Mule zwar am Anfang heftigst, aber er stützt nicht ab und erholt sich dann wieder
Ein P200 reicht scheinbar ... er läuft auch rein als Mule-Client und sämtliche Arbeiten laufen auf einer 80GB-133er-Festplatte ab ... für alles andere nutze ich einen anderen Rechner

Ich werde mir Deine Antwort nochmal in einer ruhigen Minute anschaun, damit ich es auch richtig verstehe ... aber momentan verstehe ich das so, dass mule erstmal wieder ein paar Quellen freigeben muss, damit die "komplett roten" Dateien geladen werden können.
Zur Zeit aber ich über 90 Dateien in meinem Donwload stehen, weil ich aus drei Rechnern einen gemacht habe - also muss wohl erstmal etwas fertig werden.

Aber danke erstmal für Deine umfangreiche Antwort

Divi

[vorlost]

unter max. Connection stehen jetzt "400 In 5 Sekunden 60"

Ich würde den 2.Wert die "60" auf 35 besser 30 stellen...
60 ist auf jeden Fall zu hoch.
Oder die 400 höher....

Das sind so die Werte die ich nutze:
bei 450 - 35(2.Wert nicht mehr !!!)
bei 400 - 30(2.Wert nicht mehr !!!)

Mich würde mal interessieren mit wie vielen Quellen der Esel fertig werden muß bei 90 !!! Dateien. Ich habe ihn mit ca. 15.000 Quellen bisher getestet. Ab ca. 2000 Quellen muß der "FastReaskMode" dafür sorgen das wir nicht unseren Platz in der Warteschlange verlieren.

Vorlost...