am effizientesten Winsock-Design für Hochlast-Netzwerk-Anwendung

Question

Ich weiß, es ist eine allgemeine Frage, aber ich brauche Ihre Empfehlungen über eine TCP-Server/Client-Anwendung.

Der Server sollte nur eine Verbindung gleichzeitig verarbeiten. Der Server sendet Livebilder (ein Frame ist ca. 50 KByte und 20 Frames pro Sekunde) an den verbundenen Client.

Eigentlich beim Start der Server-und Client-Anwendungen Verbindung hergestellt ist und diese Verbindung soll für immer am Leben gehalten werden, in der Theorie.

Mein Punkt ist, dass, da Server Live-Bilder sendet, Verzögerung muss minimal sein, so Was ist die beste Praxis für das Schreiben eines solchen (einfachen) TCP-Servers und Clients, und wie Serialisierung/Deserialisierung von Bildern, so dass "minumum Verzögerung "Ziel wird erreicht?

Vielen Dank im Voraus,

Grüße

Answer 1

Eine Möglichkeit ist es, die Daten unter Verwendung von UDP statt TCP zu senden.

Wenn Sie dies tun, ist es möglich, dass einige der UDP-Pakete verloren gehen (vom Netzwerk fallen gelassen). Daher benötigt Ihr Code eine Methode (z. B. Sequenznummer in den Paketköpfen), um verlorene Pakete zu erkennen.

Wenn ein TCP-Paket verloren geht, überträgt TCP es erneut, was zu einer Verzögerung führt. Es ist möglich, dass für Ihre Anwendung, wenn ein Paket verloren geht, Sie vielleicht nur auf dieses verlorene Paket verzichten, es nicht erneut übertragen möchten, diesen Videorahmen nicht anzeigen (oder nur den Teilrahmen anzeigen) und dann den nächsten anzeigen Rahmen.

Es hängt von der Anwendung:

• streamen Sie in Dosen/vorbespielte/Nicht-Echtzeit-Video, in dem Sie/Anzeige jeden Rahmen empfangen möchten, auch wenn einige von ihnen zu einer Verzögerung führen ?

• Streamen Sie Live-Video, wenn Sie den aktuellen Frame in nahezu Echtzeit anzeigen möchten (und selbst wenn einige vorherige Frames verloren gegangen sind, möchten Sie nicht verzögern, während sie erneut übertragen werden)?

---

In Bezug auf der Winsock-Architektur, der TransmitFile oder TransmitPackets APIs ist sehr effizient: sie im Kernel ist ausführen, anstatt Umläufe zwischen Ihrem Benutzermodus Code verursachen und O/S-Kernel-Modus-Code wie jeder Puffer übertragen wird.

---

"minumum Verzögerung" Ziel ist

erreicht

Sie Verzögerung einige möchten, Jitter zu vermeiden: besser ein kleines haben (zB 150 ms) mit fester Verzögerung, als eine Verzögerung was von 2 bis 120 ms variiert. Siehe http://www.google.ca/search?hl=en&q=jitter+network

Answer 2

Ich bin nicht super-autoritär, aber ...

Lassen Sie uns etwas Mathematik tun. 50K pro Bild (das sind Bytes, oder?) bei 20 Bildern pro Sekunde ist etwa 1 Megabyte pro Sekunde. In Bezug auf die Kommunikation sind das 10 Megabit pro Sekunde. Das ist ein fairer Teil, aber sehr machbar. Stellen Sie sicher, dass Sie über 100-Megabit-Geräte verfügen.

Die schnellsten APIs dafür sind die langweiligen alten blockierenden "send" und "recv" Anrufe (* 1). Es gibt andere Aufrufe, die die Windows IO-Typ-Completion-Ports ausführen und was nicht; Verwenden Sie sie nicht für diese Anwendung (weil (a) sie übertrieben sind und (b) sie eine App skalierbarer machen)

Ziehen Sie in Betracht, die Nagle auszuschalten (die NODELAY-Option).

(* 1) wahrscheinlich. Die tatsächliche Literatur über die schnellste Winsock Anrufe ist sehr mangelhaft.