eMule0.30a enkeyDEV.6

[Red-Hawk]

Base version: eMule0.30a



Binaries: eMule0.30a-enkeyDev.6-Binaries.zip
Binaries (ed2k):http://ed2k://|file|eMule0.30a-enkeyDev.6-Binaries.zip|1543516|5AE2B870530BF18AB14DBA125883A 587|/
Sources: eMule0.30a-enkeyDev.6-Sources.zip
Sources (ed2k): http://ed2k://|file|eMule0.30a-enkeyDev.6-Sources.zip|2088285|7FCB3E212095D17AE3F46EC2644F3C 8B|/


Mirror: http://enkeydev.altervista.org



Changelog:

EDT (Estimate Download Time - see below)
PNR (Partfile Name Recovery - see below)
ICS (Intelligent Chunk Selection - substituted to ECS, see below)
L2HAC (Lowid to Highid Automatic Callback)
RSA-CIDE (secure identification that grants userhash ownership, now you can give credits to old clients - default)
Releaser bar
IS (Intelligent Spreading)
SLS (Save/Load Sources)
File icons displayed in every list
Notifier (latest enkey version)
Download all ed2k in clipboard
Source list indented
Create source ed2k from downloads
Use hostname in sources instead of IP
Messaging preferences
Save A4AF preference
A4AF source number shown (as "+n")
Multiple-instance (if you use "ignoreinstances" string in command line, this allows an emule per application directory)
Show partial chunks - from ICS protocol extension
Mod version string (slugfiller) implemented: "enkeyDev.6"
Mod version string shown in client detail window.
Category tab control lengthen
Icon set completely changed with icons based on Everaldo ones - see below (thanks also to dkaox, Girard747, Gobelet)
Webserver icons changed accordingly
New icons to identify eDev mules (gray cross: eDev features compatible clients, blue cross: full enkeyDev clients)
Icons management changed: non-emules always shown with their icons
Italian translations updated
Friend-slot disabled
Full-chunk-transfer forced
File priority modifiers changed
Push small files
Show compression gain
Some other little changes



EDT (Estimate Download Time)

This works only between EDT compatible versions.
It lets you known how much it will take to download from a specific source and is updated every reask (as the QR).
The requester can see the EDT in "Remaining" column. The provider can see EDT for enqueued clients in their details window (N.S. means EDT "Not Supported" by that client).
To have a reliable statistic, EDT performs no estimation until about 30 clients start download (and that can take very much). Anyway this is VERY experimental. Do not take EDT for an oracle, if the provider changes a file priority or shares another file or a million other things, your EDT changes consequently!

ICS (Intelligent Chunk Selection) vs ECS

This feature is the same as in earlier eDev mods. We chose to implement this because we find ECS incomplete.
Keep in mind that enkeyDev mod is pro-releasers, then the priority is to make a chunk sharable as fast as possible and help releasers spreading the file as fast as possible. We believe THIS should be the priority for every emule client, and because of this we chose to keep implement ICS:
- to avoid two or more users choose to download the same chunk, ECS relies only on randomness: users choose randomly *hoping* to choose a different chunk each; in ICS users exchange infos about what chunk is being downloaded ATM, then a user can choose the less-downloaded (priority: spread the file faster)
- in ICS the user preference "first/last chunk" take importance only when there are NO rare chunks (priority: spread the file)
- in ICS requesting state does not count (priority: finish the chunk and share it)

An example over all.

With ECS, if you have 8 sources and every chunk is owned by at least two of them, then every chunk is "common": you are allowed to choose the first/last, otherwise you will choose the longest-to-finish.
Then a couple of sources quit, and you'll never finish the file...

With ICS, the same situation is a release-mode one, then you will choose the shortest-to-complete chunk that is not being downloaded ATM by any other client. This increase the probability you and the other clients would have downloaded different chunks and keep (globally) a complete source for the file, though a couple of sources quit...

PNR (Partfile Name Recovery)

This feature writes and keeps updated the file "config\PNRecovery.dat" that will help you recover files when you lose the ".met". For each record in the file, the part number, ed2k link and file name are saved in fixed lenght format.

New icons



Cumulative protocol resource infos

Tags used:
0x3C (EDT) - QR packet used also for EDT info
0x3D (ICS) - partial chunk info exchange supported
0x3E (L2HAC) - specify not standard reask time (15' to 60' allowed)
0x55 (Mod string - slugfiller)

Emule protocol extension:
0x8E (ICS) - partial chunk info

Protocol Changes:
- QR packet (TCP): 8 unused bytes filled with EDT
- QR packet (UDP): 8 bytes added for EDT
- socket timeout modified to 60 seconds (from original 40) to help L2HAC

[Borg-King]

@Red-Hawk

Du hast bei dem 1.Link auf die Binaries ein http:// zuviel drin und daher funktioniert der Link so nicht,ändere das doch bitte!

Danke

[Anonymous]

endlich mal ein mod mit icon-erklärung, sehr lobenswert.

[Borg-King]

Hmm kleiner Zwischenbericht.

25.09.2003 03:26:29: 'sqmupq [ePlus]' has failed the secure identification, V2 State: 0
25.09.2003 03:26:29: RSA-CIDE: received invalid public key
25.09.2003 03:26:29: RSA-CIDE: Public key deleted because untrustable
25.09.2003 03:26:29: 'http://emule-project.net' has failed the secure identification, V2 State: 0
25.09.2003 03:26:29: RSA-CIDE: received invalid public key
25.09.2003 03:26:29: RSA-CIDE: Public key deleted because untrustable
25.09.2003 03:26:29: 'http://emule-project.net' has failed the secure identification, V2 State: 0
25.09.2003 03:26:29: RSA-CIDE: Public key deleted because untrustable
25.09.2003 03:26:29: 'icebird [emule.de] v6 webservice' has failed the secure identification, V2 State: 0
25.09.2003 03:26:30: RSA-CIDE: Public key deleted because untrustable
25.09.2003 03:26:30: 'http://emule-project.net' has failed the secure identification, V2 State: 0
25.09.2003 03:26:30: RSA-CIDE: Public key deleted because untrustable
25.09.2003 03:26:30: 'Dr.Evil' has failed the secure identification, V2 State: 0
25.09.2003 03:26:30: RSA-CIDE: received invalid public key
25.09.2003 03:26:31: RSA-CIDE: Public key deleted because untrustable
25.09.2003 03:26:31: 'http://emule-project.net' has failed the secure identification, V2 State:

eMule v0.30a eDev6 Statistics

Clients
Client-Software
eMule: 1869 (95.3%)
v0.39: 12 (0.6%)
v0.30: 1284 (68.7%)
v0.29: 298 (15.9%)
v0.28: 155 (8.3%)
alt: 115 (6.2%)
eD Hybrid: 47 (2.4%)
eDonkey: 6 (0.3%)
xMule: 1 (0.1%)
MLdonkey: 17 (0.9%)
cDonkey: 0 (0.0%)
Shareaza: 21 (1.1%)
Unbekannt: 11
Port
Identifikation (pos : neg): 1 (0.05%) : 1431 (76.57%)
problematisch: 0
Gebannt: 0
Gefiltert: 18


Schwache Leistung,wenn das für mich bei denen dann auch zutrifft,na dann guten Nacht.Ist das ein spezieelles Problem mit RSA-CIDE und wenn ja was machen?Ausserdem wie erkenne ich wenn mal ein User Secure ist ohne das ich alle Details ansehehen muss um den Status von RSA-CIDE SUI zuerfahren,hier gibt es wohl kein Icon,das wurde wohl vergessen.Dl noch 0 UL ok max 0,2 unter dem eingestellten Limit.

[Xman]

Borg-King,
bei RSA-CIDE Mods werden nur Mods als sicher erkannt die ebenso RSA-CIDE verwenden, darum der kleine Wert erfolgreicher Identifizierungen.

Der Unterschied zum gängigen SI ist, daß bei der ersten Identifizierung der public key zum Userhash passen muß und nicht wie bei SI beliebig sein kann.

[Red-Hawk]

Hier mein Status und der Test is für mich zuende

eMule v0.30a eDev6 Statistics [Red-Hawk [emule.de]]

Transfer
Session ULL Ratio: 1.03 : 1
gesamte ULL Ratio: 1.05 : 1
Uploads
Session
Hochgeladen: 935.98 MB
Aktive Uploads: 4
Wartende Uploads: 427
Upload Sessions: 307
erfolgreiche Upload-Sessions (total): 265 (86.32)
fehlgeschlagende Upload-Sessions (total): 42 (13.6
durchschnittlicher Upload pro Session: 3.53 MB
durchschnittliche Upload-Dauer: 21:33 Minuten
Totaler Overhead (Pakete): 21.60 MB (416K)
Gesamt
Downloads
Session
Heruntergeladen: 907.17 MB
beendete Downloads: 2
Aktive Downloads: 2
Gefundene Quellen: 547
Download Sessions: 524
erfolgreiche Download Sessions: 431 (82.3%)
fehlgeschlagende Download Sessions: 93 (17.7%)
durchschnittlicher Download pro Session: 2.10 MB
durchschnittliche Downloadzeit: 14:59 Minuten
durch Komprimierung gewonnen: 14.54 MB
durch Datenfehler verloren: 0 Bytes
Teile gerettet durch I.C.H: 0
Totaler Overhead (Pakete): 13.75 MB (386K)
Gesamt
Verbindung
Session
Allgemein
Erneute Serververbindungen: 0
aktive Verbindungen (geschätzt): 28
durchschnittliche Verbindungen (geschätzt): 35
Verbindungsspitze (geschätzt): 304
Verbindungs-Limit erreicht: 0
Upload
Upload-Geschwindigkeit: 11.75 KB/s
Durchschnittliche Uploadrate: 11.67 kB/s
max. Uploadrate: 12.49 KB/s
max. durchschnittliche Uploadrate: 11.67 KB/s
Download
Download-Geschwindigkeit: 6.42 KB/s
Durchschnittliche Downloadrate: 11.31 kB/s
Max Downloadrate: 30.61 kB/s
Max Downloadrate Durchschnitt: 11.47 kB/s
Gesamt
Zeit Statistiken
letzter Reset der Statistiken: Mittwoch, 24.09.2003, 19:49:25
Zeit seit letztem Reset: 1 Tage 2 Minuten
Session
Gesamt
Abschätzungen
Clients
Client-Software
Port
Identifikation (pos : neg): 2 (0.10%) : 1339 (69.06%)
problematisch: 0
Gebannt: 0
Gefiltert: 0
Server
funktionierende Server: 57
Server mit Login-Fehlversuchen: 16
gelöschte Server: 110
Gesamt: 73
gesamte Benutzeranzahl: 1299041
gesamte Dateianzahl: 96919725
Rekorde
max. funktionierende Server: 91
max. Nutzer Online: 1300909
max. Dateien verfügbar: 97132846
freigegebende Dateien