Hallo Amateur27,
| Zitat: |
|
"Amateur27" (Nickname) schrieb:
Lol das Stürzt schon 100 gleichzeitigen Verbindungen ab und beim Surfen
auf mehrer Seiten auch.
|
Mit 100 gleichzeitigen Verbindungen bringen wir einen Windows Explorer
(
nicht Internet Explorer) unter Windows XP auch zum Absturz, bei
"günstigen" Bedingungen schaffen wir sogar einen Bluescreen.
Was wir damit sagen wollen: Es dürfte wesentlich davon abhängen, welcher
Art diese Verbindungen sind. Die höheren Protokollschichten dürfte dabei
eher nebensächlich sein, die Anzahl Verbindungen pro Zielhost wären da
schon interessanter.
| Zitat: |
|
Amateur27 schrieb:
Wie wärs wenn die Schrott Router zurück genomm werden und mal
ordentlich Hardware ausgeliefert wird?!
|
Für uns als Betreuer der Service-Foren gilt:
[X] Wir geben nichts! 
Scherz beiseite: Wenn hier Fehler wie der hier in Rede stehende
beschrieben werden, dann versuchen wir zweierlei:
• Den Fehler nachzuvollziehen, also feststellen, unter welchen
konkreten Bedingungen er auftritt. Dafür sind uns sachdienliche
Hinweise immer willkommen. Kann er nachgestellt werden, leiten wir
die Fehlerbeschreibungen an die Qualitätssicherung weiter, die sich
dann ggf. mit dem zuständigen Produktmanagement in Verbindung setzt
und entscheidet, was zu tun ist. Sobald
wir die Weiterleitung
versendet haben, sind wir raus aus dem Spiel.
• Wenn klar ist, unter welchen konkreten Bedingungen der Fehler
auftritt, kann man möglicherweise auch Workarounds erarbeiten, also
Lösungen, die geeignet sind, den Fehler zu umgehen, damit man
dadurch nicht so eingeschränkt wird.
Wir vermuten, dass es die Anzahl der aktiven Verbindungen pro Zielhost
ist, die den Reboot auslöst. Als Verursacher kommen neben P2P-Software
(die man diesbezüglich einstellen kann) vor allem auch sogenannte
"Downloadbeschleuniger" in Betracht. Dann bestünde die Umgehungslösung
darin, diese "Downloadbeschleuniger" zu deinstallieren.
Die Beschreibung von "Acidcyberdude" stützt diese Vermutung, aber nicht
nur das: Ähnliche Phänomene gab es früher auch schon beim Speedport
W 701V und dem Speedport W 900V. Auch damals ging es um 6-8 parallelle
TCP-Verbindungen zu
einem Host (und entsprechender Auslastung),
auch damals konnten wir das nicht nachstellen: Mit 24 Verbindungen zu
zwölf verschiedenen Hosts und voller Auslastung der Verbindung passiert
es nämlich nicht. Solche "Downloadbeschleuniger" wiederum installieren
wir erst gar nicht.
Warum? Nun, damit verlassen wir den Bereich des eigentlichen Supports,
aber wer weiß, vielleicht gelingt es uns ja, den einen oder anderen
davon zu überzeugen, dass bestimmte Software-Tools irgendwie "böse"
sind.
Solche Tools werden oft von RFC-Ignoranten (HTTP 1.1 erlaubt genau zwei
parallele Verbindungen zwischen einem Client und einem Server) mit
ausgeprägt egoistischer Attitüde entwickelt. Interessant ist sicher
auch, was unter http://support.microsoft.com/?kbid=282402 in der
Microsoft Knowledgebase darüber nachgelesen werden kann:
| Zitat: |
|
Microsoft Knowledgebase schrieb:
Das Erhöhen der maximalen Anzahl von Verbindungen auf mehr als
zwei stellt eine Verletzung der Internetstandards dar. Microsoft
empfiehlt, diese Vorgehensweise nicht außerhalb von geschlossenen
Netzwerken einzusetzen.
|
Für FTP gibt es solche sozial motivierten Vorschriften zwar nicht in den
RFCs (und wenn doch, wüssten wir nichts davon), aber das Prinzip bleibt
das gleiche:
Wenn ein Anbieter seinen Server für n Nutzer (und somit 2*n
gleichzeitige Sessions) auslegt und gleichzeitig den Throughput pro
Session auf 3000 Kbit/s begrenzt und dann jemand auf die Idee verfällt,
"Wenn ich sechs parallele Session aufbaue, bekomme ich das Dreifache der
mit zugedachten Leistung", dann ignoriert er offenbar, dass er seine
Interessen über die aller anderen stellt.
Für den Betreiber eines Servers ist dieses Verhalten technisch dagegen
kaum zu unterbinden. Zwar wäre es noch einfach, serverseitig die Anzahl
der Verbindungen zu einer IP-Adresse auf zwei festzulegen, das hat aber
den Nachteil, dass Nutzer hinter NAT/Proxy-Lösungen ggf. auch deutlich
benachteiligt würden. (Das hängt von der Anzahl der Clients hinter dem
NAT oder Proxy ab.) Darum wird das nur selten gemacht.
Es ist nicht grundsätzlich zu verurteilen, wenn man versucht, das Beste
herauszuholen, beispielsweise indem man das TCP-Empfangsfenster (RWIN)
vergrößert, um bei Downloads von entfernten Servern (gemeint ist eigent-
ich die Latenz) die Übertragungsraten nach oben zu schrauben. Der Weg,
einfach soviele Sessions zu
einem Server aufzumachen, dass die
Bandbreite des eigenen Anschlusses immer ausgeschöpft werden kann, ist
jedoch mehr als nur fragwürdig: Für jede einzelne TCP-Verbindung bedarf
es eines "Sockets" und diese sind ein rares Gut auf gut besuchten
Servern. Überall, wo begrenzte Ressourcen von der Allgemeinheit genutzt
werden, gelten ungeschriebene oder geschriebene (wie bei HTTP) Regeln,
die ein gewisses, soziales Verhalten als angemessen festlegen.
Forciert wird das Problem durch Presseberichte, die Tools, die es
eigentlich nicht geben sollte, in den höchsten Tönen preisen, wiewohl
diese keine technische Innovation bieten, sondern gleichsam nur mit 180
km/h und abgesägtem Auspuff durch eine Lärmschutzzone "brettern".
Uns ist natürlich klar, dass wir als Foren-Betreuer die Gesamtsituation
nicht ändern werden, dazu sind wir wahrlich zu kleine Lichter. Vermut-
lich gibt es solche "unsozialen Tools" auch auf unserer Download-
Plattform (softwareload.de). Aber wenn wir ab und zu einmal jemanden
davon überzeugen können, dass nicht alles, was technisch machbar ist,
auch sinnvoll sein muss, dann soll uns das auch genügen.
Außerdem möchten wir vermeiden, dass bei Ihnen der Eindruck entsteht,
dass wir die oben aufgeführten Argumente dazu nutzen wollen, einen
Fehler "wegzureden": Denn trotz der Schuldzuweisung an die Program-
mierer solcher Tools ist und bleibt es ein Fehler des Speedports,
wenn er einfach rebootet. Wahrscheinlich - mit unseren bescheidenen
Mitteln können wir dies nicht en detail prüfen - stellt die Firewall der
Geräte einen "SYN Flood to Host", also eine DoS-Attacke Ihres Rechners
zu einem Host im Internet, fest. Es ist nun Aufgabe der Firewall, diese
"Attacke" zu blockieren. An diesem Versuch scheint sie zu scheitern, so
dass der Router rebootet.
Da der anzunehmende Fehler in der Firmware des Routers stecken dürfte,
kann er auch nur durch eine neue Firmware behoben werden. Ob und wann
eine solche verfügbar sein wird, entzieht sich unserer Kenntnis.
Beeinflussen können wir dies auch nur dann, wenn wir eine möglichst
aussagekräftige und genaue Fehlerbeschreibung weiterleiten. Um uns zu
wiederholen: Dafür sind uns sachdienliche Hinweise immer willkommen.
Mit freundlichen Grüßen
Ihr T-Home-Team
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
http://forum.t-online.de/ -> Service-Foren
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---