[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   Xtreme MOD (http://www.emule-web.de/board/xtreme-mod/)
-   -   Fehler: Download session disconnect error 10053 (http://www.emule-web.de/board/11455-fehler-download-session-disconnect-error.html)

littletiga 6. October 2006 19:14

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...........

Xman 6. October 2006 20:20

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

littletiga 6. October 2006 20:46

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.

Xman 7. October 2006 08:15

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 ?

littletiga 7. October 2006 10:39

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.

Xman 7. October 2006 11:11

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.

littletiga 7. October 2006 11:17

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.

Xman 7. October 2006 13:51

nee.. Bug ist da keiner.. hängt schon mit Deinem System zusammen. schließlich schreibst Du oben:

Zitat:

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.
foglich wirkt sich der Fehler in Deinem System nur unterschiedlich aus... was aber auch purer Zufall sein kann, da die Reihefolge der clients auf die man trifft auch purer Zufall sind.

littletiga 7. October 2006 17:15

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?

Xman 8. October 2006 07:39

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 ?

littletiga 8. October 2006 07:52

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.

Arkos 21. October 2006 16:21

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....

littletiga 21. October 2006 16:29

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.

Arkos 21. October 2006 17:00

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.

littletiga 21. October 2006 17:15

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.

Xman 21. October 2006 17:36

Zitat:

da kommen manchmal pro Client 300 Anfragen pro paar Sekunden per UDP
ich frag mich wie Du das siehst wenn Du nicht die Debug-Version nimmst ?

littletiga 21. October 2006 17:38

Welche debugversion?

Arkos 21. October 2006 17:47

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?

Xman 21. October 2006 19:04

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.

Arkos 21. October 2006 19:24

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.

littletiga 31. October 2006 00:44

@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.

Xman 31. October 2006 08:31

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.

seppl12 31. October 2006 08:35

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.

littletiga 31. October 2006 08:38

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?

seppl12 31. October 2006 09:09

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:

Im Moment ist keine firewall von fritz drauf
Und eine andere firewall?
Hast auch wirklich schon jegliche installierte Software von AVM deinstalliert?

Xman 31. October 2006 10:38

wenn Du nix zum Hochladen hast dann brauchst Du ja auch kein Nafc.

Pachnes 31. October 2006 18:50

Das gleiche Problem hat ein user meiner community auch:
 
Moin,

und Tschüss

Xman 31. October 2006 19:13

er hat gar keine Nachteile dadurch. NAFC ist wie USS ein zuschaltbares Feature, kein Muß. Ansonsten gilt was ich oben schrieb.

littletiga 6. November 2006 15:08

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.

Xman 6. November 2006 15:23

wie wärs mit nem screenshot des Statistikgraphen damit ich weiß was Du mit "Nafc schlägt aus" meinst.

littletiga 6. November 2006 15:45

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]

Xman 7. November 2006 08:57

ok.. habs mir angesehen und möchte darauf antworten:
Zitat:

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?
die Socketabbrüche haben damit nichts zu tun. Socketabbrüche sind ziemlich normal. Schau Dir mal meine Statistik an:

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.

seppl12 7. November 2006 09:27

Zitat:

Zitat von littletiga
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.

Ich weis nicht woher du diesen Wert hast (empirisch geraten?), aber kein BS und TCP/IP Protokoll unterstützen das. Führt nur daszu, das deine gesendeten Daten "ungünstig" gesplittet werden (erhöht den overhead).

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.

littletiga 7. November 2006 15:06

@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.

seppl12 7. November 2006 16:54

Zitat:

Zitat von littletiga
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.

Richtig! Bei Tunnelprotokollen, wie bei DSL typischen PPPoE, wären prinzipiell alle Werte unter 1492 einstellbar. Diesen Wert braucht man im BS nur verstellen, wenn man mit seinem Provider Probleme hat, http Seiten zu öffnen. Planloses verändern der MTU im BS und im Xtreme, und da auch noch unterschiedlich, führt i.a. zwangsläufig zur Erhöhung des Overheads. Daher mein Vorschlag, dein Upload Limit fest und niedriger einzustellen ... war nur ein Vorschlag fürs testen.

Zitat:

Zitat von littletiga
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.


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:

Zitat von littletiga

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.


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:

Zitat von littletiga
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.

Inwieweit die Nutzung von NAFC bei der Verwendung eines Routers Sinn macht, muß jeder für sich selbst entscheiden. Ob bei dir noch andere Rechner mit Bandbreitenverbrauch am Router hängen, spielt da sicher eine entscheidende Rolle. Daher mein Vorschlag, NAFC zu deaktivieren ... wie gesagt, war nur ein Vorschlag fürs testen.

edit/
Zitat:

Zitat von littletiga
Ps: das ich das mit der firewall nicht beantwortet hab, tut mir leid. habs wohl übersehen oder so.


Und was ist mit der Fritzsoftware ...

littletiga 7. November 2006 18:19

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.

Xman 7. November 2006 19:48

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.

littletiga 7. November 2006 20:50

@xman
kann man was an dem sendepuffer in xp ändern?

seppl12 7. November 2006 23:22

Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:

Zitat von littletiga
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.

Ich benutzte auch einen Router und fahre den auch mit 50 neue Verbindungen pro 5 sec mit dem Unterschied, das mein Router da mitspielt ... hab dir einen Screenshot angehängt mit meiner Uploadkurve und den aktiven Verbindungen. Man sieht die Zwangstrennung, was aufgrund des "Reask aller Quellen nach IP Wechsel" auf das gleiche rauskommt, wie ein Neustart ... und ich seh bei mir keine deutlichen Uploadschwankungen.

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.

Xman 7. November 2006 23:26

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
so isses (leider). Hatte gehofft, daß sich mit Obfuscation hier eine deutliche Verbesserung abzeichnet.. aber nix da.

@littletiga
nee. Windows benutzt eine Standardvorgabe von 8192 die der Xtreme Programmtechnisch verändern kann.


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:43 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102