Es gibt möglicherweise mehrere Möglichkeiten, dies in Windows zu tun:
Eine Anwendung selbst kann die Download-Geschwindigkeit implizit begrenzen, indem sie ihre eigene Bitrate überwacht und bei Bedarf zwischen recv()
oder read()
auf dem Socket schläft.
Ich vermute, Internet Download Manager installiert sich möglicherweise selbst als lokalen HTTP-Proxy und konfiguriert die Browser so, dass alle Anfragen über ihn weitergeleitet werden. Und verwendet dann seinen eigenen Netzwerkcode, um den Download mit einer geeigneten Rate zu streamen, wobei die einfache Technik verwendet wird, die ich oben beschrieben habe. Schauen Sie nach, ob ein HTTP-Proxy für Ihren Browser konfiguriert ist - das sollte ein guter Hinweis sein, wenn dies der Fall ist.
Eine andere Technik besteht darin, einen Winsock Layered Service Provider oder Filtertreiber zu verwenden. Geben Sie netsh winsock show catalog
über die Befehlszeile ein (es sind bereits viele Systeminstallationen installiert).
Und Winsock selbst hat eine alte QOS-API , die Traffic-Shaping auf einem bestimmter Sockel. (Und wenn Speicher dient, hat es sogar eine Systemrichtlinien-Unterstützung, wo es extern außerhalb der App konfiguriert werden kann).
Ich brauche das für ein Projekt, das ich unter Linux mache. Ich bemerkte, dass die Übertragung die Download-Geschwindigkeit einschränken konnte. Wenn du durch ihren Quellcode spähst, kannst du überall Locken finden.
Damit scheint libcurl eine gute API für C \ C ++ - Programme zu sein. Die API sieht nicht so schlecht aus und die Dokumentation auch nicht.
siehe CURLOPT_MAX_SEND_SPEED_LARGE und CURLOPT_MAX_RECV_SPEED_LARGE in:
%Vor%und die libcurl-Startseite
@ selbie zeigt dir in die richtige Richtung. Ich möchte nur ausarbeiten:
Der Empfänger kann wirklich nur die Geschwindigkeit für große Downloads steuern. Bei sehr kleinen Downloads steuert TCP-Slow-Start die Bandbreite. Nicht ganz so kleine Downloads (bis zur festgelegten TCP-Fenstergrößenbeschränkung) werden so schnell ausgeführt, wie es die Verbindung zulässt, da die TCP-Flusssteuerung von ACKs abhängt und der Absender nicht auf ACKs wartet. Bei mittelgroßen Downloads (bis zur Socket-Puffergröße) bestätigt das Betriebssystem das Paket sofort. Diese werden so schnell ausgeführt, wie es die Verbindung zulässt, und die Anwendung hat keine Kontrolle. Nur wenn der Socket-Puffer gefüllt ist, kann die Anwendung recv
verzögern und einen Rückstau verursachen, der die Übertragungsrate begrenzt. Lösungen für den Netzwerkstack (QOS oder Filtertreiber) werden für kürzere Übertragungen benötigt.
Wenn das Protokoll eine Möglichkeit bietet, den Sender zu bitten, die Übertragungsgeschwindigkeit einzustellen, wäre das am effektivsten.
Unter Linux habe ich keine Ahnung, wie es eigentlich gemacht wird, aber Sie könnten immer den Quellcode von Anwendungen sehen, die dies tun (zB wget
mit --limit-rate
) oder nur strace
, um das betroffene System zu verstehen Anrufe.
Wenn ich in einer Netzwerkanwendung eine Bandbreitenbeschränkung programmieren müsste, würde ich das einfach nach jeder Pufferübertragung tun: Ich würde die aktuelle Bandbreite berechnen und würde die geeignete Verzögerung warten (ohne zu übertragen), um ein Überlaufen der Begrenzung zu vermeiden / p>
Unter Linux können Systemaufrufe poll
und select
einige Zeit warten, bis Ein- oder Ausgabe verfügbar ist. Und um zu warten, verwenden Sie usleep
oder nanosleep
Systemaufrufe, etc.