9
Delay auf TCP-Pakete unter Windows 7
Hallo zusammen,
ich möchte gerne einen Delay von 300 ms auf alle ausgehenden TCP-Pakete von einem bestimmten Port (und nur diesem) implementieren. Das Ganze unter Windows 7.
Kann mir jemand sagen, ob das prinzipiell möglich ist, und wenn ja wie? Leider habe ich bei meiner bisherigen Recherche nur Lösungen für Linux gefunden.
Danke!
ich möchte gerne einen Delay von 300 ms auf alle ausgehenden TCP-Pakete von einem bestimmten Port (und nur diesem) implementieren. Das Ganze unter Windows 7.
Kann mir jemand sagen, ob das prinzipiell möglich ist, und wenn ja wie? Leider habe ich bei meiner bisherigen Recherche nur Lösungen für Linux gefunden.
Danke!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 394696
Url: https://administrator.de/contentid/394696
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
9 Kommentare
Neuester Kommentar
Nein, nicht dass ich wüsste.
Wieso möchtest du das haben? Eventuell kann man dir hier anderweitig helfen?
Wieso möchtest du das haben? Eventuell kann man dir hier anderweitig helfen?
Moin,
Windows bietet solche Mögluchkeiten nicht "out-of-the-box". Das müßte man sich mut dem Compiler selbst schnitzen. Also: Prinzipiell möglich, aber nicht sinnvoll umsetzbar.
Einfacher ist es, das am Router/Gateway/Netzwerktap zu machen.
Einfach einen Linuxrechner vor den Windowsrechner klemmen und den als Verzögerungsgerät konfigurieren.
lks
Danke für die Klärung! Im konkreten Setup ist die Variante mit dem Linux-Rechner leider nicht umsetzbar.
Du könntest natürlich auch clumsy o.ä. ausprobieren:
http://get-cmd.com/?p=4056
Oder auf Basis von windivert selbst was schreiben.
lks
http://get-cmd.com/?p=4056
Oder auf Basis von windivert selbst was schreiben.
lks
Clumsy klingt als könnte es mir helfen - danke für den Hinweis! Das schaue ich mir mal genauer an.
Auch hier danke für die Info und die schnelle Antwort!
Hintergrund ist der folgende:
Ich habe einen FTP-Client mit unsauberer Protokoll-Implementierung: er wartet beim Datentransfer von Server zu Client nicht auf Abschluss der Übertragung auf dem Datenport, sondern schließt die Verbindung direkt nach Erhalt des FINs auf dem control port, das leider in manchen Fällen vor dem letzten Datenpaket ankommt.
Die saubere Lösung wäre natürlich, die Implementierung auf Client-Seite klarzuziehen, das ist aber aus verschiedenen Gründen nicht möglich. Somit bleiben die prinzipiellen Optionen, die Server-Implementierung anzupassen, sodass das FIN auf dem control port erst rausgeht, wenn das ACK fürs letzte Datenpaket empfangen wurde - oder eben sicherzustellen, dass das FIN auf dem control port nicht vor dem letzten Datenpaket ankommt. Auf letzteres hat meine Ausgangsfrage abgezielt.
Hintergrund ist der folgende:
Ich habe einen FTP-Client mit unsauberer Protokoll-Implementierung: er wartet beim Datentransfer von Server zu Client nicht auf Abschluss der Übertragung auf dem Datenport, sondern schließt die Verbindung direkt nach Erhalt des FINs auf dem control port, das leider in manchen Fällen vor dem letzten Datenpaket ankommt.
Die saubere Lösung wäre natürlich, die Implementierung auf Client-Seite klarzuziehen, das ist aber aus verschiedenen Gründen nicht möglich. Somit bleiben die prinzipiellen Optionen, die Server-Implementierung anzupassen, sodass das FIN auf dem control port erst rausgeht, wenn das ACK fürs letzte Datenpaket empfangen wurde - oder eben sicherzustellen, dass das FIN auf dem control port nicht vor dem letzten Datenpaket ankommt. Auf letzteres hat meine Ausgangsfrage abgezielt.
Zitat von @luftikus:
Ich habe einen FTP-Client mit unsauberer Protokoll-Implementierung: er wartet beim Datentransfer von Server zu Client nicht auf Abschluss der Übertragung auf dem Datenport, sondern schließt die Verbindung direkt nach Erhalt des FINs auf dem control port, das leider in manchen Fällen vor dem letzten Datenpaket ankommt.
Ich habe einen FTP-Client mit unsauberer Protokoll-Implementierung: er wartet beim Datentransfer von Server zu Client nicht auf Abschluss der Übertragung auf dem Datenport, sondern schließt die Verbindung direkt nach Erhalt des FINs auf dem control port, das leider in manchen Fällen vor dem letzten Datenpaket ankommt.
Was für ein Client ist das denn? Das ist ziemlich daneben, weil die Datenverbindung eigentlich unabhängig von der Kontrolverbindung ist.
Die saubere Lösung wäre natürlich, die Implementierung auf Client-Seite klarzuziehen, das ist aber aus verschiedenen Gründen nicht möglich.
Mußt Du einen bestimmten Client nutzen? Ansonsten würde ich einfach den Client wechseln.
lks
Leider kann ich weder Details zum Client geben, noch kann er verändert oder ausgetauscht oder sonst was
werden... Blöd, was?
Ich denke aber, dass mir der Hinweis auf Clumsy geholfen hat und dieses Tool entweder schon selbst einen workaround bringt oder zumindest dabei hilft, eine angepasste Server-Software zu testen.
Herzlichen Dank allerseits!
werden... Blöd, was?
Ich denke aber, dass mir der Hinweis auf Clumsy geholfen hat und dieses Tool entweder schon selbst einen workaround bringt oder zumindest dabei hilft, eine angepasste Server-Software zu testen.
Herzlichen Dank allerseits!
Sollte Clumsy für dich nicht funktionieren, müsstest du dir selbst einen NDIS Intermediate bzw. NDIS Filter Treiber schreiben. Das klingt jetzt komplexer als es in der Praxis ist. Es gibt bereits "do-nothing" beispiele. Also gehe ich davon aus, dass man hier nur an der richtigen stelle eine if abfrage mit einem Timeout einbauen müsste.
