Download beginnt aber bricht sofort wieder ab. Warum?

[Pacer]

Hi, ich benutze nun seit einer Weil emule, inzwischen auch den LSD-Mod 0.29c/LSD10c, aber das Problem dass ich habe, trat auch mit der Original-Software auf.

Also der Download eines Files beginnt von irgendeiner Quelle. Es steht ein Speed von 0.0K da und nach ein paar Sekunden verschwindet es einfach wieder. Also wenn ich mir meinen Upload so ankucke, dann bekommen die Clients meistens eine ganze Weile Daten von mir.

Woran liegt so etwas?

MfG, Pacer

[Xman]

Pacer,
woran das liegt kann ich Dir nicht sagen. Was ich Dir aber sagen kann, daß wir dies alle ab und zu haben.
Du kannst mal in Deinen Statistiken nachschauen unter fehlgeschlagenen Downloadsessions. Dieser Wert sollte im Bereich zwischen 35% und 15 % liegen. Schau ihn aber erst nach ein paar Stunden emule-Laufzeit an, sonst ist der Zufallsfaktor noch zu groß.

mfG
Xman

[Pacer]

Sind 50% nicht doch ein bisschen zu viel? Was haben denn andere Leute so für ein Verhältnis?

eMule v0.29c-LSD10c Statistics [Friedtjoff]
Transfer
Downloads
Session
Heruntergeladen: 18,41 MB
beendete Downloads: 0
Aktive Downloads: 4
Gefundene Quellen: 2738
Download Sessions: 53
erfolgreiche Download Sessions: 28 (52,8%)
fehlgeschlagende Download Sessions: 25 (47,2%)
durchschnittlicher Download pro Session: 673 KB
durchschnittliche Downloadzeit: 8:31 Minuten
durch Komprimierung gewonnen: 165,01 MB
durch Datenfehler verloren: 36,28 MB
Teile gerettet durch I.C.H: 0
Totaler Overhead (Pakete): 3,07 MB (63K)
Gesamt
Heruntergeladen: 1,94 GB
beendete Downloads: 0
Download Sessions: 3736
erfolgreiche Download Sessions: 1866 (49,9%)
fehlgeschlagende Download Sessions: 1870 (50,1%)
durchschnittlicher Download pro Session: 1,06 MB
durchschnittliche Downloadzeit: 8:36 Minuten

[Xman]

Pacer,
sind zu viel, ja!
Standardempfehlung: Schraub Dein Hardlimit mal runter.

Übrigens: Falls Du einen Router benutzt kann dies auch zu mehr Fehlschlägen führen.

[Blomy]

Pacer, wie Xman schon sagte, erst nach ein paar Stunden
gucken. Beim Start habe ich auch teilweise 50/50 und brauche bis zu
24 Std. um auf reale Werte zu kommen.

eMule v0.29c [ikAbOt 0.6 beta3] Statistics
Download Sessions: 789
erfolgreiche Download Sessions: 616 (78,1%) (active: 14, paused: 0, no needed part: 21, corruption: 0, timeout: 39, cancelled: 0, out of part: 25, exception: 0, others: 517)
fehlgeschlagende Download Sessions: 173 (21,9%) (paused: 0, no needed part: 3, corruption: 14, timeout: 3, cancelled: 0, out of part: 1, exception: 3, others: 149)

[Unikum]

Also ich denke mal das es evtl Clients sind die noch in Warteliste sind aber schon ne andere ip haben (durch neustart oder zwangstrennung) .... Der Muli kann ja nicht in Realtime alle Clients checken ob einer noch on ist bzw die Ip gewechselt hat..... wenn man nun an Platz 1 gerät und der upper ist nicht mehr da dann kann nix kommen. Wenn man aber zuvor was gegeben hat dann rutscht man in der warteschlange vor wenn der User dann wieder gefunden wird.

Ich denke mal das dieses die logischste Sache ist.

Greets
Unikum

[Xman]

Unikum,
wie das bei der Zwangstrennung läuft liest Du am besten hier:
http://www.emule-web.de/board/viewtopic.php?t=4992

[Unikum]

@Xman
Wie das funzt mit der Zwangstrennung is schon klar....
Mein Posting bezog sich mehr auf das erste von Pacer.

Er hatte ja nicht das Prob das er getrennt wurde sondern hat beobachtet das wenn ein Down anfängt der Wert auf 0.0 kb steht und dann einfach verschwindet.
Wenn der upper in seiner Queue stand und nun durch Zwangstrennung ne neue IP hat muss dieser erst wieder gefunden werden. So hab ich das gemeint.

Wat solls die Files werden schon kommen wenns dunkelblau iss....

In diesem Sinne

Greets
Unikum

[Xman]

Unikum,
ich hab genau den Link darum gepostet, weil ein 0-uploader nichts mit Zwangstrennung zu tun hat.

[Unikum]

@Xman
Natürlich gibts da noch die 0-uploader da haste natürlich vollkommen Recht ....
Der Effekt sieht dann ganz klar auch so aus

Greets
Unikum

[Blomy]

Unikum, den Effekt kenne ich auch. Der Client verbindet,
0.0 Geschwindikeitsanzeige und nach ca. 30 bis 60 sec ist er wieder weg.
Und das ist dann eine fehlgeschlagener Download.

Schlimmer sind die Buben, die dir 1 Byte schicken. Das sind dann die Leecher.
Bei Aktivierung des "Uploader belohnen" hoffen sie, mit diesem 1 Byte, schneller
in deiner Warteschlange vorzurücken. Was ja theoretischerweise auch
funktionieren könnte.

[Xman]

blomy,

Bei Aktivierung des "Uploader belohnen" hoffen sie, mit diesem 1 Byte, schneller
in deiner Warteschlange vorzurücken. Was ja theoretischerweise auch
funktionieren könnte.

Das stimmt nicht ganz. Die Leecher wissen, daß ein Download im emule erst dann angerechnet wird, wenn mindestens genau 1 000 000 Bytes übertragen wurden. Ich denk sie geben das Byte nur um einen Eintrag in die clients.met zu bekommen.

float CClientCredits::GetScoreRatio(uint32 dwForIP) {

// Check the client ident status
if((GetCurrentIdentState(dwForIP) == IS_IDFAILED || GetCurrentIdentState(dwForIP) == IS_IDNEEDED) &&
theApp.clientcredits->CryptoAvailable() == true){
// bad guy - no credits for you
return 1.0f;
}

// Cache value
const uint64 downloadTotal = GetDownloadedTotal();

// Check if this client has any credit (sent >1MB)
if(downloadTotal < 1000000)
return 1.0f;

// Cache value
const uint64 uploadTotal = GetUploadedTotal();

// Factor 1
float result = (uploadTotal == 0) ?
10.0f : (float)(2*downloadTotal)/(float)uploadTotal;

// Factor 2
float trunk = (float)sqrt(2.0 + (double)downloadTotal/1048576.0);
if(result > trunk)
result = trunk;

// Trunk final result 1..10
if(result < 1.0f)
return 1.0f;
else if(result > 10.0f)
return 10.0f;
else
return result;
}

PS: reiner Zufall daß ich den Code grad da hab

[Blomy]

Und mir auf die Augen haust. Danke Schön
Aber wie immer, eine perfekt Antwort. Wieder etwas schlauer.