一般的な質問であることは承知していますが、TCP サーバー/クライアント アプリケーションに関する推奨事項が必要です。
サーバーは、一度に 1 つの接続のみを処理することになっています。サーバーはライブ画像 (1 フレームは約 50K で、毎秒 20 フレーム) を接続されたクライアントに送信しています。
実際にはサーバーとクライアント アプリケーションの起動時に接続が確立され、この接続は理論的には永久に維持されるはずです。
私のポイントは、サーバーがライブ画像を送信しているため、遅延を最小限に抑える必要があるため、そのような (単純な) TCP サーバーとクライアントを作成するためのベストプラクティスと、「最小遅延」の目的が達成されるように画像をシリアル化/逆シリアル化する方法は何ですか?
前もって感謝します、
よろしく
1つの方法は、TCPの代わりにUDPを使用してデータを送信することです。
これを行うと、UDPパケットの一部が失われる（ネットワークによってドロップされる）可能性があるため、失われたパケットを検出するためのメソッド（パケットヘッダーのシーケンス番号など）がコードに必要になります。
TCPパケットが失われた場合、TCPはそれを再送信するため、遅延が発生します。アプリケーションの場合、パケットが失われたときに、失われたパケットを再送信せずに、このビデオフレームを表示せずに（またはフレームの一部のみを表示して）、次のフレームを表示したい場合があります。フレーム。
アプリケーションによって異なります。
缶詰/事前録画/非リアルタイムのビデオをストリーミングしていますか？フレームの一部で遅延が発生した場合でも、すべてのフレームを受信/表示したいですか？
現在のフレームをほぼリアルタイムで表示したい（そして、前のフレームが失われたとしても、再送信中に遅延させたくない）ライブビデオをストリーミングしていますか？
winsockアーキテクチャの観点から、TransmitFileまたはTransmitPacketsAPIは非常に効率的です。各バッファが送信されるときにユーザーモードコードとO / Sカーネルモードコードの間でラウンドトリップを引き起こすのではなく、カーネルで実行されます。
「最小遅延」の目標が達成されます
ジッタを回避するために、ある程度の遅延が必要になる場合があります。2〜120ミリ秒の遅延よりも、小さい（たとえば、150ミリ秒）固定遅延を使用する方が適切です。http://www.google.ca/search?hl=en&q=jitter+networkを参照してください
私は超権威的ではありませんが...
計算してみましょう。1 秒あたり 20 フレームで 1 画像あたり 50K (つまりバイトですよね?) は、1 秒あたり約 1 メガバイトです。通信用語では、これは毎秒 10 メガビットです。それはかなりのビットですが、非常に実行可能です。全体で 100 メガビットの機器があることを確認してください。
このための最速の API は、退屈な古いブロッキング "send" および "recv" 呼び出し (*1) です。Windows IO タイプの完了ポートなどを実行する他の呼び出しがあります。このアプリケーションには使用しないでください ((a) 過剰であり、(b) アプリのスケーラビリティを高めるため)。
Nagle (NODELAY オプション) をオフにすることを検討してください。
(*1) たぶん。実際の最速の Winsock 呼び出しに関する実際の文献は非常に不足しています。