Diese Frage ist das Ergebnis von zwei weiteren Fragen, die ich in den letzten Tagen gestellt habe.
Ich erstelle eine neue Frage, weil ich denke, dass sie mit dem "nächsten Schritt" in meinem Verständnis der Steuerung des Sende- / Empfangsflusses zusammenhängt, auf den ich noch keine vollständige Antwort erhalten habe.
Die anderen verwandten Fragen sind:
Eine Frage zur Interpretation der IOCP-Dokumentation - Mehrdeutigkeit des Puffereigentums
Nicht blockierende TCP-Pufferprobleme

Zusammenfassend verwende ich Windows I / O Completion Ports.
Ich habe mehrere Threads, die Benachrichtigungen vom Abschlussport verarbeiten.
Ich glaube, die Frage ist plattformunabhängig und hätte die gleiche Antwort, als würde man auf einem * nix * BSD Solaris-System dasselbe tun.

Also, ich brauche ein eigenes Durchflusskontrollsystem. Fein
So sende ich sende und sende, viel.Wie weiß ich, wann ich mit dem Einreihen der Sendesignale beginnen soll, da die Empfängerseite auf X begrenzt ist?

Nehmen wir ein Beispiel (das meiner Frage am nächsten kommt): FTP-Protokoll.
Ich habe zwei Server; Einer ist auf einer 100-MB-Verbindung und der andere auf einer 10-MB-Verbindung.
Ich bestelle, dass die 100-MB-Datei eine 1-GB-Datei an die andere (die 10-MB-verknüpfte) sendet. Es endet mit einer durchschnittlichen Übertragungsrate von 1,25 MB / s.
Wie wusste der Absender (der mit 100 MB verknüpfte), wann er die Sendung halten sollte, damit der langsamere nicht überflutet wird? (In diesem Fall ist die "zu sendende" Warteschlange die eigentliche Datei auf der Festplatte.)

Eine andere Möglichkeit, dies zu fragen:
Kann ich von der Gegenseite eine Benachrichtigung erhalten, dass Sie Ihre Sendungen zurückhalten? Ist es in TCP integriert oder muss ich dies für das sogenannte "zuverlässige Netzwerkprotokoll" tun?

Ich könnte meine Sendungen natürlich auf eine feste Anzahl von Bytes beschränken, aber das hört sich für mich einfach nicht richtig an.

Again, ich habe eine Schleife mit vielen Sends an einen Remote-Server, und irgendwann muss ich innerhalb dieser Schleife festlegen, ob ich diese Sendung in die Warteschlange stellen soll, oder ich kann sie an die Transportschicht (TCP) weiterleiten..
Wie mache ich das? Was würden Sie tun? Wenn ich vom IOCP eine Abschlussbenachrichtigung erhalte, dass der Sendevorgang abgeschlossen wurde, stelle ich natürlich andere ausstehende Sends aus.

Eine weitere Designfrage zu diesem Thema:
Da ich benutzerdefinierte Puffer mit einer Sendewarteschlange verwenden soll und diese Puffer zur Wiederverwendung freigegeben werden (daher wird das Schlüsselwort "delete" nicht verwendet), wenn eine Benachrichtigung "send-done" eingegangen ist, muss dies erfolgen Verwenden Sie einen gegenseitigen Ausschluss für diesen Pufferpool.
Mit einem Mutex werden die Dinge verlangsamt, also habe ich nachgedacht. Warum sollte nicht jeder Thread über einen eigenen Pufferpool verfügen, sodass für den Zugriff auf ihn, zumindest wenn die erforderlichen Puffer für einen Sendevorgang abgerufen werden, kein Mutex erforderlich ist, da er nur zu diesem Thread gehört.
Der Pufferpool befindet sich auf der Ebene des lokalen Thread-Speichers (TLS).
Kein gemeinsamer Pool impliziert, dass keine Sperre benötigt wird, impliziert schnellere Operationen, ABER impliziert auch, dass mehr Speicher von der App verwendet wird, da selbst wenn ein Thread bereits 1000 Puffer zugewiesen hat, der andere, der gerade sendet und 1000 Puffer zum Senden benötigt, dies tun muss hat diese seinen eigenen zugewiesen.

Ein anderes Problem
Sagen Sie, ich habe die Puffer A, B, C in der Warteschlange "Zu senden".
Dann erhalte ich eine Abschlussbenachrichtigung, die besagt, dass der Empfänger 10 von 15 Bytes hat. Sollte ich vom relativen Versatz des Puffers aus erneut senden, oder wird TCP dies für mich erledigen, d. H. Das Senden abschließen? Und wenn ich sollte, kann ich sicher sein, dass dieser Puffer der "als nächstes zu sendende" in der Warteschlange ist, oder könnte es beispielsweise der Puffer B sein?

Dies ist eine lange Frage und ich hoffe, keiner wurde verletzt (:

Ich würde mich freuen zu sehen, dass sich jemand die Zeit nimmt, um hier zu antworten. Ich verspreche, ich werde für ihn doppelt stimmen! (:
Danke euch allen