compressed parts support für mldonkey

[TripleM]

auch wenn ich grad ned an den paketen "schnüffeln" mag/kann, denk ich trotzdem, das gerade auch, weil uploadtest mehrfach erfolgreich stattgefunden hat, der patch zumindest zum testen freigegeben werden könnte. falls irgendwelche probleme auftauchen sollten, bin ich jederzeit ganz ohr, und bereit, diese möglichst schnell aus der welt zu schaffen!! (mag grad ned im tracker auf savannah posten, da ich diesen ned vollspamen möchte)


so long,

[spiralvoice]

Ich habe gestern einige Uploadtests gemacht und diese mit Wireshark kontrolliert.
Dein Patch scheint soweit in Ordnung zu sein, eine 50MB-Datei wurde korrekt gesendet.

Ich habe den Test zuerst mit eMule 0.47c -> eMule 0.47c gemacht, in der eMule-Statistik
werden 50MB transferiertes Volumen aufgeführt, was in Ordnung ist.

Dann mit MLdonkey 2.8.2 + Patches -> eMule 0.47c gemacht, in der eMule-Statistik
werden 87MB transferiertes Volumen aufgeführt, diese Diskrepanz ist Dir ja auch
schon aufgefallen.

Mittels mlnet.log und Wireshark kann ich nun nachweisen, dass MLDonkey die Blöcke
tatsächlich mehrfach sendet, dies passiert auch in der ungepatchten Version!
Das gleiche gilt für die Version 2.7.0, die ich soeben getestet habe.

EDIT: Mulus

configure: checking SVN revision
Version: 0.18.1 - SCM: 384

hat das gleiche Problem.

[TripleM]

...
Mittels mlnet.log und Wireshark kann ich nun nachweisen, dass MLDonkey die Blöcke
tatsächlich mehrfach sendet, dies passiert auch in der ungepatchten Version!
Das gleiche gilt für die Version 2.7.0, die ich soeben getestet habe.

EDIT: Mulus

configure: checking SVN revision
Version: 0.18.1 - SCM: 384

hat das gleiche Problem.

hab auch schon mehrfach theoretisch mal drüber nachgedacht, wo genau es dazu kommen könnte, das der mldonkey pakete doppelt verschicken will.

(im folgenden chunk=180kb)
der reine uploadpart in DonkeyFiles ist dabei soweit in ordnung, die vorhandenen chunkanforderungen je client werden der reihe nach abgearbeitet und dann entfernt, kann also eigentlich nicht das prob sein, aber wer weis.

der nächste punkt ist die einordnung der anforderungen in diese liste in DonkeyClient.new_chunk. der scheint mir aber auch ok, zumindest was ganze chunks angeht, da identische chunkanforderungen eigentlich nicht in die liste eingeordnet werden. nur falls subchunks angefordert werden, könnte dieses problem auftauchen.

nun hab ich aber beobachtet, das wenn irgendeine datei komplett komprimiert übertragbar ist, und auch so übertragen wird, es scheinbar nicht zu mehrfachsendungen kommt, deswegen vermute ich, das es tatsächlich in irgendeiner form zu subchunkanforderungen kommt.

Oder aber, wobei das nur eine vermutung ist, mldonkey ist in der lage auch bruchteile eines chunks in kleinere pakete (als 10kb) zu packen, zumindest als plain. wenn sich nun emule bei unkomprimierten paketen ähnlich verhält, wie bei komprimierten (er weist kleine pakete, die nicht das ende eines chunks darstellen, zurück), kann es sein, das er bestimmte abschnitte nochmal neu anfordert, und es so zu diesen mehrfachübertragungen kommt. bei komprimierten paketen ist mir das aufgefallen, da emule in dem fall den kompletten chunk als fehlerhaft ansieht.


so long,

[spiralvoice]

Das gleiche Problem wird hier diskutiert:
http://mldonkey.sourceforge.net/forums/ ... php?t=4576

[spiralvoice]

Dann mit MLdonkey 2.8.2 + Patches -> eMule 0.47c gemacht, in der eMule-Statistik
werden 87MB transferiertes Volumen aufgeführt, diese Diskrepanz ist Dir ja auch
schon aufgefallen.

Aktuelles CVS mit diesem Patch
ftp://ftp.berlios.de/pub/mldonkey/pango ... imal.patch
behebt das Problem.

Bitte testen. Ein solcher Core ist bei mir bereits im Einsatz. Ich weiss nicht, ob
es Zufall ist oder am Patch liegt, aber die Downloadgeschwindigkeit hat sich
jetzt verdoppelt, uptime allerdings nur 1h. Mehr Statistiken in den nächsten Tagen...

[TripleM]

hab gleich mal abhängige patches umgebaut. hab diesmal aber nur einen patch für beide uploadmethoden gebastelt: http://savannah.nongnu.org/patch/?5596

btw. bei mir läuft jetzt mld 2.8.2.cvs + avoid_duplicate_sending_v8_minimal + full_chunk_upload_3(alt.) + compressed_upload_10 + swarmalgo_perma_map, und das eigentlich problemlos.


so long,

[spiralvoice]

Patch ist im CVS

2007/01/11
5665: EDK: Support compressed upload, implement file read cache (TripleM)
new options:
- ED2K_upload_compression to enable compressed upload, default true
- ED2K_upload_compression_threshold, default 2000 bytes
Size difference in bytes between one zone (180 kBytes) and its compressed
counterpart, which has to occure, to send compressed parts instead of plain.
- ED2K_upload_compression_level, Zlib compression level, default 9
- ED2K_upload_compression_table_size, default 20

[spiralvoice]

Der EDK-compressed-upload patch wurde soeben aus dem CVS entfernt:
https://savannah.nongnu.org/patch/index.php?5857

Bei Usern mit hunderten von Upload-Slots erzeugte
dieser Patch unannehmbar hohe CPU-Last durch
einen schlecht programmierten Cache-Algorithmus:

http://mldonkey.sourceforge.net/forums/ ... 5786#25786

Using a weak array for the compressed zones cache is a bad idea; The garbage collector can indeed reclaim the cache content at any time.
The cache algorithms that are implemented with that datastructure aren't very good either: linear lookup search, and FIFO policy...

Mittels des o.g. Patches kann die entfernte Funktion jederzeit
wieder ins CVS hinzugefügt werden, aber nur in verbesserter Form.