Inetget wird gedrosselt

    Guten Abend /Morgen,

    Folgendes Problem :

    Ich habe eine .exe erstellt, die mir von meinem Server eine größere Datei runterlädt.

    Nur das geht nicht. Der Server schaltet nach ein paar GBs mit high-speed auf ca 35 mbit's.

    Ja, es ist Serverseitig, da ich es mit ein paar Rechnern geprüft habe.

    Und das Phänomen ist ja auch, dass der Download mit Chrome oder dem ie tadellos funktioniert. Sodass ich xampp auch ausschließen kann.

    Ja, zum Server noch :

    Windows 2019, 8 cores, 64gb RAM, 10tb Platte

    1 gbit Leitung (und darum auch die 35 mbit ein Witz)

    Mit freundlichen Grüßen

    Hi AlucardXtreme,

    und wo und wie solen wir dir dabei jetzt helfen?
    Hier ist nichts worauf man aufbauen könnte, dabraucht man durchaus mal ein paar relevante Informationen (z.B. das Skript).

    Auch wenn es nur die Funktion ist.

    Sollte ja bekannt sein.

    Und der Fehler ist einfach, dass der Windows Server die vom inetget geforderten Download drosselt.

    Und ich möchte hier halt wissen, woran es liegt? Ob ich beim inetget irgendwas ändern kann oder an dem windows server was geändert werden muss.

    Und vielleicht ist der Fehler bekannt und ich bekomme Tipps.

    Mit freundlichen Grüßen

    Da ich immer noch nicht weiß wie du inetget aufrufst (also welche Parametrer du nutzt oder auch nicht) hier ein Schuss ins Blaue:

    $INET_FORCEBYPASS nutzen, weil "By default AutoIt forces a connection before starting a download. For dial-up users this will prompt to go online or dial the modem (depending on how the system is configured). The options value $INET_FORCEBYPASS (16) disables this behavior. Disabling the behavior can be useful for persistent connects (Broadband, LAN). However, it is also required to work around certain issues in Windows Vista and Windows 7."

    Optional: $INET_DOWNLOADBACKGROUND nutzen und über schleife per inetgetinfo() auf abschluss warten, da dann auch mehrere downloads gleichzeitig möglich sind, ob das in diesem fall hilft (weil eine Datei wie z.B. zip auch mehrere Dateien beinhaltet und viele kleine Dateien runterladen dauert länger als eine Große mit der gleichen Größe).

    Windows 2019, 8 cores, 64gb RAM, 10tb Platte.

    Ich bin kein super Server experte ich kenne aber Windows 2019 nicht einmal.

    Sie meinen Windows Server 2019,
    wird bei Ihnen, über eine Interne Verbindung die Daten geladen oder von Server ans Internet zu Client am Internet?
    Setze dich mit dem Microsofts SMB Sachen auseinder, deaktiviert für eine bessere Performens alte SMB dienste im Windows.
    setze den MTU wert client und server richtig passend zu deinen netzwerkkarten.
    Microsoft ist in der hinsicht ein arsch, Windows kann nicht mal selbst entscheiden was es tun soll wenn 2x Internet angeschlossen ist.
    Wechselt er immer zwischen den Verbindungen hin und her du musst meist Windows alles sagen was du genau möchtest.

    Ist es dein eigner Server oder steht der in einer Firma ?
    Wenn es dein eigner ist, dann schlage ich vor Unraid zu nutzen, zfs pools erstellen und dann abfahrt.
    Damit könntest du locker über oder an die Geschwindigkeiten einer m.2 nvme ssd im Netzwerk herankommen.
    da würde halt die eine Festplatte nicht passen da wären mehr als 1 ratsam, sowie ecc Speicher damit deine Daten auch sicher so bleiben wie du sie drauf kopierst.

    Jap, der Server ist halt gemietet von einem Provider.

    Ecc hat er alles.

    Steht in der MTU sowas wie alle Browser erlauben aber nicht über ein Programm?


    Und MUSS auf dem Server denn FTP für autoit aktiviert sein? Weil autoit von selbst den Port 21 benutzt?

    MTU ist ein wert deiner netzwerkkarte jede netzwerkkarte hat je nach Spezifikationen einen eigenen optimalen mtu wert.
    Den Optimalen wert erkennt Windows meistens nicht meist ist ein Standard wert von 1000 oder 1500 eingetragen.

    Das heißt also dein Server steht bei einem Provider, dann fällt Unraid nach meinen Überlegungen schonmal weg weil da habe ich nur Erfahrungen im Heimnetz und du musst es um es zu nutzen einen usb stick dran stecken.^^

    Also dir geht es darum Daten mit einem Skript zu laden, es geht nicht um Datenbank Sachen ?
    Große daten mit einem Skript laden hab ich selbst keine Erfahrungen mit.

    Je nachdem was du erreichen möchtest, FTP musst du nicht nutzen ist auch sehr Sicherheitsbedenklich wenn die Daten etwas wert sind.
    Du könntest auch mit Webdriver deine Daten herunterladen, wenn die Geschwindigkeit im Browser bei dir nach einer zeit nicht langsamer wird.

    FTP "Wäre!" eine Option... Weil ja die Datei benutzer spezifisch sind und für jemand anderen nutzlos wäre.


    Aber was mich halt stört, ist es ja, dass die inetget zwar funktioniert. Aber nur in den ersten paar Sekunden auf dem windows System und es denn extrem gedrosselt wird. Wobei die datei mit Chrom oder sonst einem Browser zu 100% mit der vollen Bandbreite runtergeladen werden kann.


    Als würde halt windows bei der inetget() die Verbindung halt abbrechen. Oder die Funktion selber...

    Mit(URL,Location, 16,1) kommt auch die drossel.


    Also ich hab es beobachtet und es scheint so, dass der Server ab ca.700mb die Verbindung halt schließt und dann autoit die Verbindung neu aufbaut im Sekunden takt ca.

    Hmm...

    Also neue Feststellung,

    Wenn ich das Scrip mit der sleep() in den Schlaf schicke bleibt der Download hoch...

    Kann es sein, dass der Windows Server nur alle 10 Sekunden oder so eine neue Abfrage zulässt vom Download?

    Hab zurzeit

    Inetget ()

    Do


    Sleep(1000)

    Until download complete

    Inetclose()


    Oder ist da irgendwo der Fehler drin?

    Auch wenn Du das Problem für Dich umgangen hast: Check den Webserver (IIS)....dort kann man so viel Einstellen und vorallem Verstellen. Wenn, kann die Drosselung nur vom Server her kommen.

    Ein guter Gegentest wäre die gleich Datei mit WGET herunterzulanden....

    Ach Ja, MTU-Size ist die Paketgröße im TCP-Netz, bei LAN ist sie immer 1500. Andere Werte werden nur bei DSL oder VPN-Verbindungen verwendet damit die Datenpakete nicht framentiert werden. Ob die MTU zu groß eingestellt ist kannst Du sehr einfach feststellen: ping meinserver.com -f -l 1500

    lg

    Racer

    Racer

    naja kommt drauf an was für eine Netzwerkkarte verbaut ist.
    hat man ein Ehternetport am Mainboard belegt, ist die Annahme meistens richtig, nutzt der Server bsp. eine Mellanox connect x3 oder 4 sehen die mtu werte schon wieder ganz anders aus.

    Aber du hast recht es kann nur von einer Einstellung auf dem Server kommen.

    Zitat von Racer

    Ob die MTU zu groß eingestellt ist kannst Du sehr einfach feststellen: ping meinserver.com -f -l 1500

    Damit würdest du doch aber auf eine MTU von 1528 testen - oder?
    Um zu prüfen ob im Netz eine MTU von 1500 Bytes funktioniert müsste man ja noch IP-Header (20 Byte) und den ICMP-Header (8 Byte) abziehen.
    Also wäre der korrekte Befehl um auf eine MTU von 1500 zu prüfen folgender: ping meinserver.com -f -l 1472

    Zitat von AspirinJunkie

    Damit würdest du doch aber auf eine MTU von 1528 testen - oder?
    Um zu prüfen ob im Netz eine MTU von 1500 Bytes funktioniert müsste man ja noch IP-Header (20 Byte) und den ICMP-Header (8 Byte) abziehen.
    Also wäre der korrekte Befehl um auf eine MTU von 1500 zu prüfen folgender: ping meinserver.com -f -l 1472

    Im Grunde hast Du Recht, es kommen immer ein paar Byte vom Header dazu. Wichtig ist das hier die Paketgröße passt, sonst wird das Datenpaket fragmentiert und dann wird es richtig langsam. In meinen Lan verwende ich 4088 (Jumboframe), Bei meinen VPN musste ich den Paketgröße auf 1472 ändern (Windows meint 1500 geht eh, geht aber nicht gut), da hier ein Zertifikat dabei ist das ein bisschen Platz braucht....
    Daher Teste ich immer mit dem ping ziel -f -l 1500....wenn es passt OK, wenn nicht mit der nächsten kleineren Paketgröße (1496, 1492, ....) bis es ohne Fragmentierung funktioniert!

    lg

    Racer

    Zitat von Racer

    Daher Teste ich immer mit dem ping ziel -f -l 1500....wenn es passt OK,

    Das kann dann aber nur in einem Netz mit aktivierten Jumboframes passen.
    Bei normalen Ethernet sollte dieser Aufruf immer versagen.
    Selbst bei minimaler Funktionalität im Ethernetframe kommt man nicht auf über 1.500 MTU.
    Der Aufruf checkt aber hingegen auf eine MTU von 1528 Bytes.

    Oder anders ausgedrückt: Wenn ping ziel -f -l 1472 noch durchgeht - dann hast du eine MTU von 1.500 Bytes.

    Zitat von AspirinJunkie


    Oder anders ausgedrückt: Wenn ping ziel -f -l 1472 noch durchgeht - dann hast du eine MTU von 1.500 Bytes.

    Ich kann Dir nicht sagen ob das in der Windowswelt die 8 Byte schon abgerechnet werden oder einfach nur anders angezeigt. Fakt ist bei einem unmodifizierten Netz ist der Default Wert auf 1500.

    Anzeigen kannst Du es mir "netsh interface ipv4 show interface"

    Bie mir steht dann bei Ethernet0 4074 - ich verwende Jumboframes da es meine Switches und Endgeräte können. Aber am Ende ist es egal, Hauptsache es passt für das eigene LAN bzw. DSL/VPN/...
    Ich finde, wenn man diverse Performances Probleme hat sollte man das austesten und nachstellen...könnte zum Erfolg führen!

    Zitat von Racer

    Ich kann Dir nicht sagen ob das in der Windowswelt die 8 Byte schon abgerechnet werden oder einfach nur anders angezeigt.

    Werden sie nicht.
    Können sie auch nicht, da der Ping-Parameter "-l" die gewünschte Größe des Sendepuffers angibt - was in einem ICMP-Paket die Nutzlast ist.
    Dieser ist durch die MTU und die Header des Pings (ICMP-Header + IP-Header) begrenzt.
    Würde der Windows-Ping frech einfach an dieser Stelle 28 Byte hier runterrechnen wäre der Parameter falsch, da er nicht mehr die Größe der Nutzdaten definiert sondern irgendetwas anderes (den Parameter gibt es nicht für die Ermittlung der MTU - er wird hierfür lediglich missbraucht)
    Er würde sogar undefinierte Größen im Bereich 0 bis 27 erzeugen. (negative Angaben...)

    Hab es auch gerade hier getestet bei einer definitiven MTU von 1500: ein Ping mit -l 1473 versagt zuverlässig.