![]() |
hallo community, bitte helft mir, bekomme immer diese fehlermeldung: Download session ended: Disconnected: CClientReqSocket::Disconnect(): Error 10053: Eine bestehende Verbindung wurde softwaregesteuert durch den Hostcomputer abgebrochen. Bekomme keine downloadsessions mehr hin, geht gar nix mehr. Ich weiss nur das es ein socketproblem ist. Bitte um Hilfe........... |
puhh.. das einzige was mir dazu einfällt wäre ein Problem mit der Firewall. Da dies aber kein Bug im Xtreme ist sondern eher in die Kategorie Support-Request gehört hab ich das mal getrennt. Um Dein Problem zu lösen bräuchten wir aber noch mehr Informationen. Beachte bitte die Checkliste vor dem Posten |
Mein betriebssystem is xp pro, xtreme 5.3, 1&1-1536/192, Router avm fritzbox phone wlan 7050, hardwarefirewalldienst deaktiviert, Softwarefirewall zum test deinstalliert und antivir das gleiche. Hab im xtreme fast alle funktionen an. hab ich aber alles schon aus gemacht, hilft auch nix. Bin alles andere als ein leihe was emule betrifft. beschäftige mich schon seit 2 jahren etwas intensiver damit. So ein fehler hatte ich noch nie. Hab im internet nur raus gefunden das es ein socketfehler ist. |
nur mal um sicherzugehen: das Problem besteht bei ALLEN Downloadsessions ? Auch über eine längere Laufzeit ? Wie schauts aus mit Uploadsessions ? Hast Du z.B. viele Pruna Clients gefunden ist der Fehler ziemlich normal... die schließen ihre Sockets immer auf eine unübliche Methode... aber irgendwann solltest Du dann auch mal an einen normalen Client geraten. Schon mal die offi emule 0.47c probiert ? |
Also ich hab im Schnitt pro Stunde etwa 10 solche Fehlermeldungen. Manchmal geht aber auch gar nix, wo einer nach dem andern abbricht. Die Laufzeit spielt dabei keine grosse Rolle. Zu Pruna-clients hab ich fast keinen Kontakt. In den Uploadsessions sieht es nicht ganz so schlimm, aber ähnlich aus, nur das noch andere Fehlermeldungen hinzu kommen. Hab inzwischen auch mein tcp/ip-protokoll neu instaliert und es danach resettet und etliche andere sachen daran gemacht. Hat aber nichts geholfen. Es ist so, das der Client mir einen Slot gibt, dann läd er vielleicht 500 kb konstant an mich hoch, dann wird der speed auf ziemlich genau 1 kb/s reduziert und dann dauert es noch ein paar minuten bis er mit dieser Fehlermeldung disconnected. Die offi hab ich noch nicht probiert, werde ich aber noch machen. Hab grad den offiziellen emule am laufen und bekam gleich zu anfang dies fehlermeldungen: client tcp socket error 10051: Ein socketvorgang bezog sich auf ein nicht verfügbares netzwerk. oder client tcp socket error 10065: Der Host war bei einem Socketvorgang nicht erreichbar. Diese Meldungen häufen sich dann auch. |
dann haben wir zumindest mal einen Bug im Xtreme ausgeschlossen (der mich auch verwundert hätte). Auf die Schnelle konnte ich nun aber auch keine Lösung finden... vielleicht findet jemand anderes noch einen Hinweis zu besagten socket errors. |
ja, aber ich muss sagen, im offiziellen emule kommen zwar diese 2 fehlermeldungen, aber die clienten brechen nicht ab. Die laden genau so hoch wie sich das gehört. Bis jetzt konnte ich ausser diesen meldungen nichts negatives feststellen. Habe schon von mehrerern clients nen chunk bekommen. nee, der offi läd genau 9.28 mb hoch. der hat den bug nicht den ich meine. Irgendwo muss ein bug in den sockets sein, der die verbindung abbrechen lässt. |
nee.. Bug ist da keiner.. hängt schon mit Deinem System zusammen. schließlich schreibst Du oben: Zitat:
|
Hab den offi jetzt schon seit 6 stunden laufen und der oben genannte fehler ist einmal aufgetreten. Also bei weitem weniger als im xtreme. Ob das jetzt zufall ist, weiss ich nicht. Ich weiss noch nicht mal welcher socket blockiert, meiner oder der des anderen clienten. Was kann man da machen? |
probier mal im Xtreme: - andere Ports - Protokoll obfuscation aktiviert Wenn das keine Änderung bringt probier den Xtreme 5.2.2 und sag mir ob dort das gleiche Problem vorliegt. brechen eigentlich die Uploadsessions ebenso mit besagter Fehlermeldung ab ? Benutzt Du UPNP ? |
andere Ports und Protokoll obfuscation hab ich schon probiert. bringt keine Änderung. Die Uploadsessions haben zum Teil andere Fehlermeldungen, aber laufen wenigstens. Upnp nutze ich, aber nicht mit der funktion im xtreme. ich hab die fritzbox und benutze das Programm Fritz!Dsl von avm. das beinhaltet u.a. eine firewall mit automatischer upnp-zuweisung ohne das es das programm unterstützen muss. Es erkennt die ports die das jeweilige Programm öffnen will, fragt beim ersten zugriff nach der installation den benutzer ob das programm die öffnen darf und dann werden sie automatisch geöffnet. hab ich zum test aber auch schon deaktiviert. bringt auch keine besserung. |
Das hatte ich auch, habe danach auf 0.47c gewechselt und "Protocoll Obfuskation" aktiviert. > "Einstellungen" > "Sicherheit" > "Aktiviere Protokoll Obfuskation" Es sieht so aus, als hätte das neue Sicherheitsprotocoll auch seine Tücken. Jedenfalls hat es sich seither wieder gebessert. Schade, dass die Sivka Mod nicht mehr läuft... gibt keine mit diesem neuen Protokoll...... Jedenfalls rate icgh Dir, tui die 0.47c drauf, arbeite damit, und wenn's dann wieder läuft, kannst Du ja wieder eine Mod antesten. Eigentlich hat's mich ja verwundert, da ich das schon mal hatte... aber plötzlich ging's dann wieder für ein paar Wochen... UpNp-Dienst ist bei mir deaktiviert... Wie gesagt... mit der 0.47c hat's jedenfalls gebessert. Vorher hatte ich Wochenlang immer nach einigen Sekunden Upload zusammenbruch pro Channel.... das ging die ganze Zeit so... Der Upload blieb nie stabil und so kam auch kein Quellenaustausch zusammen... die Waiting List blieb beinahe down und DL gab's sozusagen nie... Ich habe fast das Gefühl, dass zu viele die Abweis Funktion eingeschaltet haben... Eventuell sollte man bei dieser Option Warbschilder hinnageln.... |
hatte die ganze zeit die 0.47c drauf. hab auch protokollobfuskation aktiviert und wieder deaktiviert. brachte aber alles nix. hab mir jetzt auch einen neuen pc mit topaktueller hardware gekauft und der fehler taucht trotzdem auf. Ich glaub, das es einfach am emule liegt, da ich auch im offi diese meldungen bekomme. |
Aber hast Du nur die erste der Optionen eingeschaltet? Oder? Und wenn Du neue Hardware hast... da musst Du ja wieder einiges Einstellen... Aber Du wirst das schon richtig erkennen... Totaler ZickZack in der Upload-Statistik... Die Verbindungen brechen nach einigen Sekunden ein, auf null Bits und erholen sich dann innert ca. 10 - 20 Sekunden auf 200 bits... aber irgend wann später kommt dann die deaktivierung der Verbindung. Bei mir kam das von der einen Sekunde auf die andere und blieb dann für Wochen... Plötzlich war die Störung wieder weg und kam dann wieder nach ca. 3 Wochen. Ich habe mich auch schon gefragt, ob das ein gekonnter Angriff auf das P2P Netzwerk ist. Wenn Du ja neue Hardware gekauft hast, alles neu installiert hast, kann's ja kein Softwareseitiger Störenfried sein, ausser der Provider hätte Restriktionen eingeführt, was ich aber nicht so recht glaube, da ja diese Meldungen überall sporadisch auftauchen. Vor allem haben ja die meisten Provider denselben BackupProvider... sonst müssten ja alle Clients davon betroffen sein. Könnte es ev. sein, dass das "Obfuskation Protocoll" einige Nebenwirkungen zeigt oder eben die Ablehne Funktion sich nicht wirklich deaktivieren lässt. (2-te Option)... Die Cracks untter Euch werden dem sicher nachgehen... Ich kann auch ein Verbose Log zukommen lassen... Wenn's erwünscht wäre... Aber es sind immer die gleichen Meldungen. Verbindung wurde vom Host - Computer (Oder auch Server) softwaregesteuert zurückgesetzt... Error 10053... Was ich auch bemerkt habe... da kommen manchmal pro Client 300 Anfragen pro paar Sekunden per UDP... immer für das gleiche File... eventuell ist das aber nur eine Nebenerscheinung des beeinträchtigten P2P Verkehrs... Wie gesagt, vor dem 0.47c, hatte ich Wochenlang nur solche Meldungen. Der UL brach nach einigen Sekunden ein und wurde unterbrochen. Die Warteliste füllte sich gar nicht, da diese vorweg aufgebraucht wurde... Übertragen wurde aber praktisch nichts, und DL gab's auch keinen, ... also eigentlich wie Anti P2P .... Ich hatte diese zwei Meldungen am laufenden Band (Eigentlich waren diese das einzige Resultat ausser einigen wenigen KiloBytes UL und DL während Stunden. Nur 10053 und hunderte UDP Anfragen für's gleiche File für den gleichen Client innerhalb einiger Sekunden. |
Der upload funzt bei mir einwandfrei, ausser das nafc ab und zu für n paar minuten spinnt. die fehler hab ich hauptsächlich im download. |
Zitat:
|
Welche debugversion? |
Im Sivka-Mod... Verbose @Ittleiga > muss man bei an- und ausschalten der Obfuskation nicht eMule neu starten, damit man einen Effekt erzielt? - bzw. die Option dann auch aktiviert oder deaktiviert wird? Oder ggf. neu connecten? |
achso ... also ich würde einfach mal ohne router direkt übers modem probieren.. dann hast Du entweder mit Sicherheit den Übeltäter gefunden oder eine Fehlerquelle ausgeschlossen. |
Also ich hab nen Modem ohne Router und... seit der 0.47c geht's wieder... Aber ich vermute gleichwohl noch, dass das mit der Obfuskation andere Probs eröffnet hat... oder sonst was im Busch ist... vielleicht täusche ich mich, aber... ich hatte nie Probs, auf einmal aber solch extreme.. Und das unter Ausschluss anderer Möglichkeiten, wie PC oder Modem usw. |
@xman Ich hab raus gefunden an was meine verbindungen Fehlschlägt. Ein kumpel und ich haben ausführliche tests gemacht und sind alle funktionen des xtreme durch gegangen indem er mir einen friendupload gegeben hat. wir sind zu dem ergebnis gekommen das alleine nafc die schuld zu tragen hat. wenn ich es an hatte bin ich bei ihm im upload sofort mit dem socket-blockierverhältnis auf nahezu 100%. sobald ich es wieder aus gemacht hab, sank es wieder gegen 0%. Das haben wir einige male probiert. und der fehler trat immer sofort auf. dachte zuerst es sei die fritzbox. war es aber nicht, denn ich hab noch 2 modems da liegen und mit denen ging es auch nicht. und ein router und 2 modems können nicht kaputt sein. dann hab ich auch einen neuen pc und ein xp das erst 2 wochen alt ist. also liegt es an nafc. Aus irgend einem grund blockiert nafc meine komplette verbindung im up und download, sodass ich viele socket-fehlermeldungen erhalte. wir haben es wirklich ausführlich getestet um ganz sicher zu gehen. @xman gib bitte ne antwort drauf, weil ich gerne hätte das man den bug beseitigt. nafc an sich finde ich nämlich eine tolle sache wenn es läuft. danke. |
da ist kein Bug im NAFC.. läuft ja bei mir und anderen auch ohne Probleme. Das einzige was Du bedenken mußt ist, daß Du mit NAFC ein dynamisches Downloadlimit bekommst. Falls Du bei Deinen Tests also nichts hochgeladen hast sondern nur runter, dann hattest Du keine Erlaubnis zum Download -> 100% Blockierung. |
Bisher schreibst du, das du dieselbe Problematik auch mit dem offiziellen client hattest ... und das hat kein NAFC. Welche Softwarefirewall(s) läuft auf dem Rechner? Nur jene von der Fritzbox? Könntest du nochmals folgendes testen wenn du Zeit hast? Deinstallier jegliche installierte AVM Software, verbinde deinen Rechner direkt mit dem DSL Modem und wähle dich beim Provider über eine einfache DFÜ Verbindung ein. |
Hab ich alles schon gemacht. Im Moment ist keine firewall von fritz drauf. und was is wenn ich von nem file noch nix hab zum hochladen? |
Wenn du nichts hochladen kannst, weil du noch keinen vollständigen chunk hast oder niemand das file haben will, kann du trotzdem runterladen. Ein evtl. Ratio wirkt erst dann, wenn du hochlädtst. Einzig was mir zu deinem Problem jetzt noch einfällt, ist es mal mit einer anderer (anderer Hersteller) Netzwerkkarte zu probieren. edit/ Zitat:
Hast auch wirklich schon jegliche installierte Software von AVM deinstalliert? |
wenn Du nix zum Hochladen hast dann brauchst Du ja auch kein Nafc. |
Das gleiche Problem hat ein user meiner community auch: Moin, und Tschüss |
er hat gar keine Nachteile dadurch. NAFC ist wie USS ein zuschaltbares Feature, kein Muß. Ansonsten gilt was ich oben schrieb. |
also, hab mein problem jetzt minimiert. Das heisst, ich habe die MTU im xtreme auf 1000 gesetzt und doppelte sendegrösse aus gemacht. Dadurch konnte nafc den upload erheblich besser stabil halten. Durch diese einstellungen hatte ich schon wesentlich weniger socket-probleme. Dann stellte ich noch die Mtu in der Registry von 1492 auf 1340 runter. Dadurch hab ich meine socket-probleme fast beseitigt. Weiss zwar nicht genau was der xtreme mit der mtu in der registry zu tun hat, weil eigentlich nutzt er ja scheinbar ne eigene mtu-einstellung. Jetzt bekomm ich nur noch socket-abbrüche im download wenn im upload ein user ist, der egal wieviel Prozent, Blockierverhältnisse hat. Denn dann hält das nafc den upload nicht mehr konstant und schlägt ab und zu aus bis über die leitungsgrenze. Deswegen hab ich als socketabbrüche im download. Hat da jemand ne lösung für? Denn dann wäre ich mein problem endgültig los. |
wie wärs mit nem screenshot des Statistikgraphen damit ich weiß was Du mit "Nafc schlägt aus" meinst. |
wenn du mir sagst wie ich das hier poste............. so, hier is es. das is auch ein gutes beispiel. Das ist meistens kein Browserverkehr oder sonstiges. Ich hatte auch schon zum test den browser und alle anderen anwendungen geschlossen. Das resultiert fast immer daraus, wenn ein user im upload ist, der socket-blockierverhältnisse verursacht. es ist auch meistens immer nur einer. [Screenshots entfernt, da IP-Adressen anderer Clients zu sehen waren] |
ok.. habs mir angesehen und möchte darauf antworten: Zitat:
eMule v0.47c Xtreme 5.3.1 Statistics Download Sessions: 3567 Successful Download Sessions: 3146 (88.2%) (active: 31, paused: 2, no needed part: 183, timeout: 619, socket: 746, out of part: 1565, exception: 0, others: 0) Failed Download Sessions: 421 (11.8%) (paused: 0, no needed part: 19, timeout: 114, socket: 282, out of part: 6, exception: 0, others: 0) Average Downloaded Per Session: 5.54 MB Average Download Time: 26:23 Minutes Out of Part sind normal abgeschlossene Downloads. Socket und Timeout bedeuten, daß der Socket wie auch immer "gestorben" ist. NAFC reguliert übrigens nicht falsch, bzw. über die Leitungsgrenze... Du hast vielmehr eine hohe Auflösung des Statistikgraphen mit dem Du jede Schwachstelle des Systems siehst. Und hier muß ich die Einstellung zum Socket-Send-Buffer ins Spiel bringen: emule schiebt die Daten nur in diesen Buffer, wann sie letztendlich tatsächlich gesendet werden entscheidet Windows ganz alleine. Ist dieser Buffer also groß (12 kb) und Du hast einen Uploadslot mit hohem Blockierverhältnis, dann schickt Windows diese 12 kb Daten *irgendwann*. Darum gibts auch diese Spitze in Deinem Upload. NAFC merkt erst ein paar Millisekunden später: "moment da sind grad zu viele Daten geflossen, dann sende ich die nächsten xxx Millisekunden mal nichts mehr". Mit einem kleinerem Sendebuffer reduzierst Du diesen Effekt. Stellst Du den Statistikgraphen auf 5 oder mehr Sekunden wirst Du diesen Effekt auch weniger sehen. Der offi client hat dieses "Problem", daß eben bei blockierenden Sockets der Upload schwankt wesentlich stärker. Dadurch, daß er den Graphen aber extrem glättet wirst Du es dort gar nicht sehen. |
Zitat:
Jetzt hoffen wir mal, das das der einzige Wert ist, den du in der Registry "verpfuscht" hast und auch kein sonstiges sogenanntes "Optimierungstool für die Registry" verwendet hast, die verschlimmbessern die Sache immer nur. Stell den MTU Wert in der Registry wieder auf seine default Wert von 1492 (Rechner rebboot). Und dann kannst du anhand der Beschreibung hier: Bei DSL-Verbindung einen Router optimalen MTU-Wert ermitteln und über die Registry einstellen. deinen MTU Wert ermitteln und in eMule setzten (evtl. auch im Router anpassen). Oben hatte ich dich gefragt, ob noch irgendeine firewall bei dir läuft und ob du jegliche AMV Software deinstalliert hast ... leider erfolglos. Anhand deines ersten Screenshots kann man erkennen, das deine Fritzbox mit den vielen Verbindungen nicht zurechtkommt und anhand der anderen beiden screenshots, das womöglich dein Upload zu hoch eingestellt ist (keine Reseven bei providerseitigen Schwankungen). Mein Vorschlag, den du mal testen könntest, NAVC deaktivieren und ein festes Upload Limit von 16 kB/s einstelln. Den Wert für Max.Verbindungen auf 200 und den Wert für Verbindungen pro 5 sec auf 20. Und nicht mehr als 2500 Gesamtquellen im eMule haben. Wärte schön, wenn du uns mit diesen Werten einen Screenshot zeigen könntest. |
@xman wenn du den sendepuffer vom xtreme meinst, so hab ich den schon die ganze zeit auf 6000 stehen. Ansonsten klär mich bitte auf, wie ich den in windows verstelle. Die hohe auflösung des statsgraphen hab ich extra so gemacht, das ich mögliche fehler sehen kann. War also absicht.Wll den graphen nicht höher stellen, da ich die fehler beseitigen will und sie nicht verdecken möchte. @seppl Das Betriebssystem muss die niedrige mtu auf jeden fall unterstützen, denn wenn du mit einem modem surfen tust, ist ne mtu von 500 ganz normal. und der xtreme unterstützt dies auch, da dadurch die schwankungen enorm weniger geworden sind. Es sind aber ca. 0,5 kb overhead mehr geworden. Alles unter 1000 mtu frisst er erheblich mehr overhead, sodass dieses verhältniss nicht mehr stimmt. deswegen 1000. Und verpfuscht hab ich auch nix, es war nur ein versuch. Ich kenne mich sehr wohl mit diesen werten aus und ziemlich vieles andere was pc betrifft auch. <--kein neuling........... firewalls hatte ich alle schon deinstalliert, auch die windowsfirewall aus usw. also ich hab wirklich alles probiert. Ich hab mittlerweile die fritzbox 7170 bekommen und die verträgt so viele verbindungen wie du sie nie aufbauen würdest. Das weiss ich weil sie im emule schon auf über 1200 verbindungen gelaufen ist. 90% des uploads is bei mir 21.6 kb/s. Ich habe auf 21 kb/s eingestellt. also puffer genug. Die schwankungen Providerseitig sind tagsüber max. 2 kb/s. Wobei man bedenken muss, das ich bei meinem dsl 2000 noch den overhead zur leitung mitbekommen hab. also hab ich einen upload von 203. Ich möchte nafc nicht deaktivieren, weil ich dann genausoweit wäre wie vorher. ich finde das es ein sehr gutes werkzeug ist, um den upload möglich hoch zu halten. Ich möchte nur, das alles möglichst fehlerfrei läuft. Ps: das ich das mit der firewall nicht beantwortet hab, tut mir leid. habs wohl übersehen oder so. |
Zitat:
Zitat:
Ja, laufen schon, aber mit den von dir beschriebenen Symptomen ... was dein erster Screenshot zu 100 % bestätigt. Daher mein Vorschlag für die Verbindungseinstellungen ... war nur ein Vorschlag fürs testen. Zitat:
Mein Provider hat mir einen 600 kbit Upload verkauft ... tatsächlich schwankt die Bandbreite zwischen 450 kbit und 520 kbit ... und das in nächster Nachbarschaft zum Knotenpunkt. Daher mein Vorschlag, dein Upload Limit fest und niedriger einzustellen ... wie gesagt, war nur ein Vorschlag fürs testen. Zitat:
edit/ Zitat:
Und was ist mit der Fritzsoftware ... |
fritzsoftware war auch schon komplett deinstalliert. Bei meinem 1.screenshot wurde der xtreme grad gestartet und hat quellen aufgebaut. ich habe 50 per 5 und 100 halboffene. das mit dem uploadlimit hab ich schon gemacht. hat aber an den sockets nichts geändert. hatte auch schon ein modem dran und der upload sah ganz genau so aus. |
wegen der MTU möchte ich noch bemerken: klar wird die Linie schöner je kleiner die MTU ist... denn eine Straße läßt sich mit kleinen Steinen viel ebener bedecken als wenn ich Felsbrocken nimm. Ein bischen Zickzack ist also durchaus normal. Höhere MTU = weniger Overhead.. zu hohe MTU ist aber wieder erhöhter Overhead, darum verwendet der offi Emule den Wert 1340. 1440 sollten aber bei jedem deutschen DSL-Anbieter drin sein. |
@xman kann man was an dem sendepuffer in xp ändern? |
Liste der Anhänge anzeigen (Anzahl: 1) Zitat:
Und über 50 % Socketabbrüche in den fehlgeschlagenen Up- und Downloads sind ganz normal, da änderst du, ich oder Xman nichts daran, egal mit welchen Einstellungen. |
Zitat:
@littletiga nee. Windows benutzt eine Standardvorgabe von 8192 die der Xtreme Programmtechnisch verändern kann. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:12 Uhr. |
Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.