eWombat 0.064E (07.11.03) Sehr wichtiger Security-Fix

[MxM.]

Usul,

ich gebe Dir Recht, daß es Clients gibt die die Verbindung nicht herstellen können, Fakt ist auch dass die Anzahl der Clients nicht über 2/3 der gesamtmenge liegt.

Dennoch, eMule ist auch hierfür schuld.


Erklärung:


ich habe endlich für meinen QSC Anschluß cFos zum laufen gekriegt. Komischerweise ist der Effekt, dass meinerseits Downloads fehlschlagen nahezu eliminiert. Statt 0 Bytes zu bekommen habe ich nunmehr Verbindungen die bei kleinen Dateien Ratzfatz auch mit mehr als 32 kb/s senden können, obwohl ich nebenbei surfe.

okok, jetzt könnte man sagen, das liegt ja am Treiber... in gewisser Weise liegt es das ja auch, sonst würde es jetzt ja nicht gehen...

Andersherum ist eMule aber selbst schuld, dass der Traffic so immens ist, dass sich Upload und Download dauernd in die Quere kommen, auch kann ich anhand von Zugriffssteuerungen einwandfrei belegen, dass nach dem connecten Via emule tagelang vollgeschüttet werde mit UDP und TCP requests...abgesehen von den Streueffekten.
Neben dem gebrandmarkten e-Mail spam, sind andere Formen von direktem P2P Spam heutzutage viel schlimmer.
eMule blockt sich hier also auf allen Leitungen sofern ich Uploade sperrt sich mein Download und umgekehrt...

Einzige Lösung (und hier muss ich böserweise leider an zig Argumente der Leecher denken) Upload beschränken, da dieser wesentlich schneller voll ist..und im ernstfall download beschränken.

Komischerweise gehts dann ja auch mit den Zahlen.




ok... jetzt weiter im Text... andere emules waren bei diesen Abbruchzahlen (und sind teilweise immernoch) besser und andere wiederum schlechter... wie erklärst du dir das...wenn doch nur die Gegenseite schuld ist ?

Warum gibts es in "Achillesferse Upload" soviele Mules die dauerhaft auf mehreren Systemen bessere Werte gebracht haben, warum sind andere kosntant schlecht ... wenn doch die Gegenseite schuld ist... bzw. es an dem nichtzustandekommen liegt... HUCH... achsoo... ja das nichtzustandekommen... also liegt doch das nichtzustandekommen doch wieder am eigenen client...


Fazit: so oder so ...ob ich nun uploadbandbreite verschwendet sehe durch real versendete pakete... oder ob es verschwendung durch garnicht erst zu versendende (der möglichkeiten wegen) pakete geht spielt keine Rolle... in jedem Fall ist der jeweilige Mule für den Traffic zuständig.


ich habe den 0063 nun also von echtzeitwarteschleife bis hin zu Mod-Anzeige auf alles beschränkt... sogar die friendshare mod erkennung habe ich abgeschalten.
SUI ist angeblieben ebenso das CS

auch den tip mit der gelöschten clients.met bin ich nachgekommen... habe tatsächlich meinen 1,3 MB File gelöscht nur um es rauszufinden....



Fazit:

Trotzdem ich sogar den Router abgebaut habe und nun per cFOS arbeite...trotz traffic shaping...UUUND sogar trotz Uploadbeschränkung auf 24kb/s von >32kb/s

das verhältnis konnte ich zwar verbessern aber nicht wesentlich

vorher: 10:11
nachher: 5:4 (10:

ganze 30 % kann man jetzt sagen... und immerhin...aber ich hab alles rausgeholt was ging. Meine Downloads schlagen jetzt eigentlich NICHTMEHR fehl...und wenn dann nur , weil die quelle offline geht.

ich checke sources am server nur alle 1600 sekunden und von anderen quellen alle 2000 minuten... der traffic ist wirklich gegen 0 verbindungen kommen dank traffic shaping eigentlich unbelastet zustande.


Testgrundlage: Niegelnagelneues frisches Win2000 SP4 (audiotechnisch notwendig)


Also ich bin immernoch sicher, hier muss DRINGEND Code-Arbeit geleistet werden.


schönen Tag noch
Max

[darkwolf]

Hi

@Usul, du hast recht, die RSA-CIDE kompatiblität funktioniert nur wenn man sich mal wieder einen neuen Userhash generieren lässt, leider lassen sich CIDE-Clients nur über die Mod-Versionen erkennen und das ist mir zu unsicher um mit 2 Schlüsselpaaren zu arbeiten.
Den Link wegen den Release-Features werde ich mir mal genau durchlesen, und mal schauen was lovelace da so gebastelt hat.

Noch ein abschliessendes Wort zu der 'Upload Sessions failed' Problematik:
(Mit der TCPIP Geschichte war ich leider auf dem Holzweg, die Timeouts gibt es weil Window intern die Sockets eine zeitlang offenhält obwohl sie nicht mehr benötigt werden...)
Hier mal ein kurzer LogAuszug:
21.07.2003 20:39:29: Upload failed: http://www.emule-pro 212.202.9.160:4662 [Übertrage not sui]
21.07.2003 21:03:44: Upload failed: jones 172.177.46.79:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:04:00: Upload failed: [Empty User Name] 80.142.240.17:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:04:17: Upload failed: [Empty User Name] 80.129.89.84:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:04:33: Upload failed: Mozartino (shareaza. 217.82.249.155:34518 [Übertrage no blocks requested]
21.07.2003 21:04:34: Upload failed: Neo 213.196.240.252:4662 [Übertrage no blocks requested]
21.07.2003 21:05:01: Upload failed: http://www.emule.de 80.142.183.217:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:05:04: Upload failed: bodykiller 82.64.120.161:4662 [Übertrage no blocks requested]
21.07.2003 21:05:10: Upload failed: [ita] devil in dusck 217.133.207.212:4662 [Übertrage no blocks requested]
21.07.2003 21:11:13: Upload failed: eMule v0.23b [Tarod. 80.129.78.183:4662 [Übertrage no blocks requested]
21.07.2003 21:11:18: Upload failed: http://emule-project 81.53.83.177:4662 [Übertrage no blocks requested]
21.07.2003 21:21:51: Upload failed: Soul_Hunter 80.178.238.151:4662 [Übertrage no blocks requested]
21.07.2003 21:25:22: Upload failed: rosl (shareaza.com) 217.226.74.28:6346 [Übertrage no blocks requested]
21.07.2003 21:53:01: Upload failed: Amistades Peligrosas 81.40.172.230:4662 [Übertrage no blocks requested]
21.07.2003 21:53:45: Upload failed: wolfspelz 80.145.180.211:4662 [Verbindung wird hergestellt no blocks requested]
21.07.2003 21:54:29: Upload failed: eMule v0.26d [.Fusio 213.54.33.118:4224 [Verbindung wird hergestellt no blocks requested]
Bis auf dem ersten Client (der ist aus dem Uploadslot rausgeflogen, weil er als unsicher identifiziert worden ist) haben alle den Upload abgebrochen, weil sie keine benötigten Teile mehr gefunden haben ('no blocks requested'). Soetwas lässt sich leider erst feststellen, wenn sich der Client versucht mit einem Upload-Slot zu verbinden, ist also überhaupt kein Grund um verzweifelt irgendwelche Schwachstellen zu suchen, höchstens um auf offizieller Seite das Protokoll zu erweitern... Auch im DebugLog stehen Meldungen warum ein Client den Upload abbricht.

cu
darkwolf

[Xman]

MxM.,
Ich kann Dir allein aufgrund des Satzbaus nicht immer ganz folgen.
Dennoch halten wir mal fest:
- man kann durch eigene Optimierungen 30% rausholen. Ok, so seh ich das auch, man kann optimieren.
- einige Versionen laufen besser als andere. Ok, auch das stimmt. Und genau daran möcht ich auch festhalten, wenn Du behauptest, daß der eigene Client zuständig für Fehler ist. Kann es denn nicht eher sein, daß Deine Gegenüberstelle so nen schlechten / falsch konfigurierten Client hat !?
Wenn ich alleine sehe, daß es Leute gibt, die ständig 2000 Verbidnungen auf haben, mit 200 gleichzeitigen Downloads, Hardlimit 1000, dann wundert es mich nicht, daß ich bei diesen Leuten connection Probleme hab.
- Es muß dringend Codearbeit geleistet werden. Wiederum ok, so seh ich das auch. Es muß aber nicht nur Codearbeit geleistet werden um die Connections zu optimieren (und darkwolf arbeitet bereits daran), sondern muß man es irgendwann mal schaffen den emule vor dem User zu schützen. Sprich emule so absichern, daß der DAU ihn nicht kaputtoptimieren kann.

mfG
Xman

[Xman]

darkwolf,
zu Deinem Auszug:
Bin mir ziemlich sicher, daß dies aber ein seltener Grund für nen fehlgeschlagenen Upload ist. Schließlich schlägt dieser sehr oft fehl bei Clients die fast nichts von einem File haben und ich hab es komplett. No blocks requestet fällt dann doch flach !?

[MxM.]

umso kurioser ist doch, dass ich mittels einstellungen das verhältnis verbessert habe.

ebenso sollten sich keine mathematischen unterschiede für abfrage-prozesse nach chunks ergeben.


sicher, dass die timeouts für die abfrageprozesse keinen einfluss haben ?

mit badwolf und den codern vom flux konnten wir durchsetzen, dass die timeout werte eisntellbar sind, da unterschiedliche leitungen unterschiedliche anforderungen haben, und wir in zusammenarbeit feststellen konnten, dass durch längere timeoutzeiten insgesamt weniger traffic mathematisch verschwendet wurde.... auch wenn er vielleicht auf einer grafischen kurve nicht durchgängig aussah... aber eigentlich sollte eh allen klar sein, dass auf den wegen über knotenpunkte gerade bei ordentlicher nutzung des internets keine upload und downloadgeschwindigkeit gleich bleiben kann.

[Usul]

Zitat von MxM.

Fakt ist auch dass die Anzahl der Clients nicht über 2/3 der gesamtmenge liegt.

Woher weißt du das, das du sagen kannst, es ist ein Fakt? Oder vermutest du es nur, auch wenn du es mit einer Sicherheit von 99% vermutest?

Dennoch, eMule ist auch hierfür schuld.

mal sehen...

ich habe endlich für meinen QSC Anschluß cFos zum laufen gekriegt. Komischerweise ist der Effekt, dass meinerseits Downloads fehlschlagen nahezu eliminiert. Statt 0 Bytes zu bekommen habe ich nunmehr Verbindungen die bei kleinen Dateien Ratzfatz auch mit mehr als 32 kb/s senden können, obwohl ich nebenbei surfe.

Sehr gute Beobachtung. Was bei dir erfolgreiche Downloads sind, sind bei anderen erfolgreiche Uploads. Wenn du deine erfolgreichen Downloads maximierst, maximierst du bei anderen die erfolgreichen Uploads. Würdest du das nicht tun, würden bei den anderen die fehlgeschlagenen Uploads höher ausfallen, OHNE das die etwas dafür können, da die Ursache, die Möglichkeit zur Verbesserung offensichtlich bei dir liegt bzw. lag.

Andersherum ist eMule aber selbst schuld, dass der Traffic so immens ist, dass sich Upload und Download dauernd in die Quere kommen, auch kann ich anhand von Zugriffssteuerungen einwandfrei belegen, dass nach dem connecten Via emule tagelang vollgeschüttet werde mit UDP und TCP requests...abgesehen von den Streueffekten.
Neben dem gebrandmarkten e-Mail spam, sind andere Formen von direktem P2P Spam heutzutage viel schlimmer.
eMule blockt sich hier also auf allen Leitungen sofern ich Uploade sperrt sich mein Download und umgekehrt...

Einzige Lösung (und hier muss ich böserweise leider an zig Argumente der Leecher denken) Upload beschränken, da dieser wesentlich schneller voll ist..und im ernstfall download beschränken.

Den Upload bei Emule einstellen ist ein Drahtseilakt, keine Frage. Treiber wie cFos helfen dabei, wie deine Überprüfungen ergeben haben. Hat auch nie jemand angezweifelt.

ok... jetzt weiter im Text... andere emules waren bei diesen Abbruchzahlen (und sind teilweise immernoch) besser und andere wiederum schlechter... wie erklärst du dir das...wenn doch nur die Gegenseite schuld ist ?
Warum gibts es in "Achillesferse Upload" soviele Mules die dauerhaft auf mehreren Systemen bessere Werte gebracht haben, warum sind andere kosntant schlecht ... wenn doch die Gegenseite schuld ist... bzw. es an dem nichtzustandekommen liegt... HUCH... achsoo... ja das nichtzustandekommen... also liegt doch das nichtzustandekommen doch wieder am eigenen client...

Das ist die einzige Sache, die mir Kopfschmerzen bereitet. Deswegen war ich auch einigermaßen beruhigt, als darkwolf seine Statistik veröffentlicht hat, was es für Gründe für fehlgeschlagene Uploadsessions gibt. Wie es scheint, ignorierst du diese Ergebnisse. Für mich sind sie etwas, was ich jetzt weiß, und nichts, was ich glaube. Dummerweise kann man mit diesen Ergebnissen nicht erklären, warum das Verhältnis bei einem Mod besser ist, bei einem anderen schlechter. Aber wenn man etwas nicht erklären kann, kann man nicht einfach von einer Möglichkeit ausgehen, die man für wahrscheinlich oder logisch hält.

Gehen wir mal davon aus, wir sind Profis, wir kennen uns mit Emule aus, wir verstehen die Schräubchen, an denen man drehen muß. Wenn bei uns etwas nicht stimmt, sei es "kranker" Upload oder Download, wir können unserem Emule helfen. Die breite Masse "normaler" User kann es nicht, sie verstopfen ihre Leitung, denke ich mal. Deswegen die vielen Fehlschläge in Verbindung mit den anderen.

Fazit: so oder so ...ob ich nun uploadbandbreite verschwendet sehe durch real versendete pakete... oder ob es verschwendung durch garnicht erst zu versendende (der möglichkeiten wegen) pakete geht spielt keine Rolle... in jedem Fall ist der jeweilige Mule für den Traffic zuständig.

Nein, es ist nicht egal, was man wie und wo verschwendet, und das hat mich an deine Post gestört, wo du die Prozentzahl der fehlgeschlagenen Uploadsessions auf den gesamten realen Upload hochgerechnet hast. Du hast vereinfacht gerechnet: "Es ist egal, ob ich bei 20k Upload 50% verschenke oder bei 10k Upload 100% Erfolg erreiche, es kommt aufs gleiche raus" Natürlich nicht mit diesen Werten, nur vom Prinzip her kam es so rüber. Und das war und ist einfach falsch. Weil die Prozentzahl nichts mit dem Upload, sondern mit den Sessions zu tun haben, und eine fehlgeschlagene Session steht nicht für verschwendeten Upload. Deswegen meine Intervention gegen deinen Kommentar.

auch den tip mit der gelöschten clients.met bin ich nachgekommen... habe tatsächlich meinen 1,3 MB File gelöscht nur um es rauszufinden....

Bloß mal nebenbei, wieso gleich löschen? Irgendwohin kopieren und nach dem Experiment wieder zurück hätte es auch getan

ganze 30 % kann man jetzt sagen... und immerhin...aber ich hab alles rausgeholt was ging. Meine Downloads schlagen jetzt eigentlich NICHTMEHR fehl...und wenn dann nur , weil die quelle offline geht.

Wie ich oben schon sagt, du hast deinen eMule jetzt optimal dafür konfiguriert, das alle anderen bessere Uploadsessionwerte erhalten. Wenn es jeder so machen würde, dann würden auch bei allen die Uploadsessionverhältnisse besser werden. Wir können in unserem Forum nur dazu beitragen. Packen wir es an

ich checke sources am server nur alle 1600 sekunden und von anderen quellen alle 2000 minuten... der traffic ist wirklich gegen 0 verbindungen kommen dank traffic shaping eigentlich unbelastet zustande.

Da über meine Leitung noch zwei Rechner im Internet sind, muß ich meine eWombat/eMule immer sehr "human" konfigurieren. Meiner Meinung nach gelingt mir das auch, ich habe mit keiner Internetapplikation irgendwelche Probleme, keine Abbrüche bei Downloads, die über mehrere Stunden gehen (ich installiere gerade Gnome unter Cygwin/X11 aus dem Internet, das dauert ), keine verlorenen Verbindungen bei ICQ, sogar Kazaa von meiner Freundin läuft ohne Probleme, wenn sie es mal anwirft. Ich kann mir nicht vorstellen, das bei mir die Leitung so dicht ist, das ausgerechnet eWombat Probleme bekommt. Trotzdem habe ich die bekannten schlechten Uploadsessionwerte.

Also ich bin immernoch sicher, hier muss DRINGEND Code-Arbeit geleistet werden.

darkwolf hat dir seine Sicht der Dinge gesagt. Mir ist nichts eingefallen, was er noch tun könnte (ihm bestimmt auch nicht). Wenn dir was einfällt, nur zu.

[MxM.]

Zitat von Xman

darkwolf,
zu Deinem Auszug:
Bin mir ziemlich sicher, daß dies aber ein seltener Grund für nen fehlgeschlagenen Upload ist. Schließlich schlägt dieser sehr oft fehl bei Clients die fast nichts von einem File haben und ich hab es komplett. No blocks requestet fällt dann doch flach !?

das ist insofern falsch, falls der gegenüber mehrere quellen hat, bei denen er sogar am gleichen chunk gleichzeitig saugt.

hast du bei dir selbst bestimmte auch schon beobachtet ein chunk der gleich an mehreren stellen schwarz wird und gleichzeitig abwechselnd die farbe hat, wo er stellen hat wo nix is.

die transferraten solcher chunks haben dann meist horrenden einfluss auf einen average nach oben




anders würde deine aussage sein, wenn wir jetzt von einem release reden...



ach übrigens darkwolf.... teilweise release ich auch nur dateien, das ergibt sich aus meienr präsenz als musiker... und die files habe dann auch nur ich.... tatsächlich wären hier abbrüche wegen no block nur möglich, falls die abfrage beendet wurde.

[MxM.]

@ Usul

Fakt ist... (auf meinem System und meinem Emule... und bei nur bei mir meßbaren werten)


altes Problem.... aber das ergibt sich eigentlich bei vorhandener Logik... da ich wohl kaum den Überblick über alle mules im netz habe.



schönen abend noch.

[darkwolf]

Hi

@Xman, der Test oben lief auf einer optimierten verbindung. Eine Funktion um den eMule/eWombat auf die eigene Internetverbindung zu optimieren wäre ideal ist aber leider nicht so leicht umzusetzen. Eine der stärken des eMule gegenüber dem eDonkey ist ja, das man alles mögliche Einstellen kann um das ganze zu optimieren. Wenn man die ganzen Einstellungsmöglichkeiten wieder wegmacht interessiert sich kein Mensch mehr dafür.

Und wenn jemand seinen eMule 'kaputt'-optimiert, selber schuld...
Ich möchte jedenfalls keinen 'Anti DAU-Mod' bauen oder sehen.

cu
darkwolf

[Usul]

Zitat von darkwolf

Den Link wegen den Release-Features werde ich mir mal genau durchlesen, und mal schauen was lovelace da so gebastelt hat.

Falls es falsch rüberkam: Der Link hat nichts mit Lovelace zu tun, es waren nur zwei Dinge, die mir bei Release Features einfielen, der Link UND Lovelace´s aktueller Mod. Dummerweise habe ich zu letzteren keinen alles erklärenden Link gefunden, da das Wissen über dessen aktuellen Thread verstreut ist.



Nur mal so als Info für "kaputte Clients". Heute hat jemand mal gefragt, ob irgend etwas gegen den Client von emule.de spricht, ich hab mich mal etwas schlau gemacht, dieser Client stellt z.B. Defaultmäßig bei den Conn. per 5 Sek. 75 (in Worten: Fünfundsiebzig). Und das ist volle Absicht. Der Vorgänger von der aktuellen Version wurde laut Seite 1,5 Millionen mal runtergeladen, da war das garantiert auch schon so, vielleicht sogar schlimmer. Sicherlich ist dieser nicht annähernd so weit verbreitet, wie diese Zahl suggeriert, aber es läßt auf eine ordentliche Größenordnung schließen. Das der Wert 75 in den meisten Fällen nicht das Gelbe vom Ei ist, brauch ich wohl nicht zu erklären. Und wir wundern uns noch über viele fehlgeschlagene Sessions und suchen die Schuld bei uns? So langsam ist das nicht mehr haltbar.

[Xman]

MxM.
ich rede mitunter auch vom releasen.

[Usul]

Zitat von MxM.

@ Usul
Fakt ist... (auf meinem System und meinem Emule... und bei nur bei mir meßbaren werten)
altes Problem.... aber das ergibt sich eigentlich bei vorhandener Logik... da ich wohl kaum den Überblick über alle mules im netz habe.
schönen abend noch.

Das ist immer das Hauptproblem, man neigt dazu, von sich auf andere zu schließen. Wie schon gesagt, wir haben den Emule (halbwegs) im Griff, aber die breite Masse nimmt das Teil und läd einfach runter, ohne sich großartig darum zu kümmern. Was wir bei uns messen oder sehen, ist daher wohl eher die Ausnahme, ich möchte nicht die Statistik von so einem Emule-Nutzer sehen, der keine Ahnung hat und einfach mal an den Knöpfen gespielt hat (und das soll jetzt nicht abwertend sein ). Solche Clients wie beschrieben, die blödsinnig Defaulteinstellungen haben UND weit verbreitet sind, machen scheinbar mehr Ärger als diese Leecher.

[darkwolf]

Hi

@Usul, ist schon richtig rübergekommen einmal Link zum Lesen und einmal Lovelace-Mod (da habe ich eh die Sourcen)

cu
darkwolf

[MxM.]

übrigens befindet sich lovelace nicht ohne grund auf meiner Ban-List. nach allgemeinen Definition hat lovelace features in seinen letzten client eingebaut die allgemein unter das topic leecher passen.

die frage mit den unterschieden der mules vor eigener haustür ist somit nicht geklärt

thema gelöschte clients.met hab ich mich nur kurz gefaßt um spucke zu sparen. selbstverständlich existiert ein backup.


Usul,

könntest du mir mittels dieser deiner Einstellung :

"Es ist egal, ob ich bei 20k Upload 50% verschenke oder bei 10k Upload 100% Erfolg erreiche, es kommt aufs gleiche raus" Natürlich nicht mit diesen Werten, nur vom Prinzip her kam es so rüber. Und das war und ist einfach falsch.

mir inhaltlich widerlegen, wenn ich dir zahlentechnisch mathematisch transferzahlen und deren verhältnisse bei upload -> success:failed belege ?

ohne, daß du dabei die programme die ich benutze in frage stellst, oder wir über die diskussion darüber bis ins kleinste detail der grundprogrammierung von windows und servern und tcp/ip flags kommen ?



es ist tatsächlich bei mir so, dass ich nicht im verhältnis was du oben erwähnt hast..aber es ist wirklich so, dass BEI MIR .... die success werte direkt positiv werden, sofern ich nicht am leitungslimit agiere.... oder andersherum...sie werden schlechter sobald ich diesem näherrücke.


so gern ich dieses argument selbst beseitigen würde, aber wäre es nicht bei mir selbst so, würde ich wie du argumentieren.

ich spare nur genau die bytes, die mathematisch nach der bei mir vor ort errechneten formel nicht funktionieren.

auch muss ich zB zum guten funktionieren meiner QSC Leitung für mein LAN eine eigene IP festlegen 192.168.0.1 für mich selbst, obwohl ich kein router und kein netzwerk habe... da ich ohne diese einstellung aufgrund des abfragespreadings des dsl modems nahezu keine leitung bekomme.

und das heißt auf deutsch

ping www.heise.de hat dann 16ms, 31ms, zeitüberschreitung, zeitüberschreitung packet loss: 50%

technik die begeistert, behoben durch 192.168.0.1


übrigens jedem der probleme hat, empfehle ich das.

[Xman]

Zitat von darkwolf

Hi

@Xman, der Test oben lief auf einer optimierten verbindung.

Na genau diese optimierte Verbdinung haben wir wohl nicht und darum Connection Timeouts. Und gneau um diese Connection Timeouts gehts ja. Sind diese wirklich nur die Schuld des anderen Clients ? Wie kann man diese optimieren ?

Im übrigen noch ein weiterer Aspekt. Wenn wir uns die fehlgeschlagenen Downloadsessions anschauen, dann betrachten wir auch nen falschen Wert. Denn diese Sessions sind Sessions, wo wir eine Verbindung zur Gegenstelle aufgebaut haben. Doch wie schaut es mit den Downloadsessions aus, wenn ein anderer gar nicht zu uns connecten kann. Dann wird er wohl erst gar nicht als fehlgeschlagene Downloadsession aufgenommen !?