0

サーバーとクライアントの間に 1 対 1 の接続があります。サーバーはリアルタイムのオーディオ/ビデオ データをストリーミングしています。

私の質問は奇妙に聞こえるかもしれませんが、複数のポート/ソケットを使用する必要がありますか、それとも 1 つだけを使用する必要がありますか? 複数のポートを使用した方が速いですか、それとも単一のポートを使用した方がパフォーマンスが向上しますか? ビデオ用に 1 つ、オーディオ用に 1 つ、メッセージ専用のポートを用意する必要がありますか? それとも、すべてを 1 つのポートにパッケージ化する方が簡単ですか?

私の現在の問題の 1 つは、現在のフレームのサイズ (バイト単位) がフレームごとに変化する可能性があるため、最初に現在のフレームのサイズを送信する必要があることです。私はネットワーキングにかなり慣れていませんが、送信されている特定のオブジェクトの正しい範囲を自動的に検出するメカニズムを見つけていません。たとえば、2934 バイトの長さのパケットを送信した場合、そのパケットのサイズを受信者に通知する必要があるでしょうか?

私は最初に、フレームが入ってくるのと同じ速さでパッケージ化しようとしましたが、受信側が適切なバイト数を取得できないことがあることがわかりました。ほとんどの場合、送信するよりも速く読み取り、部分的なフレームしか取得しません。適切なバイト数だけをできるだけ早く取得する最善の方法は何ですか?

それとも、私が低すぎるように見えて、オブジェクトの送信を処理するために使用されるより高いレベルのクラス/フレームワークがありますか?

4

2 に答える 2

1

オブジェクトメカニズムを使用して、インターリーブ方式でデータを送信する方がよいと思います。このメカニズムは、複数ポートのメカニズムよりも高速に動作する可能性があります。

例えば：

class Data { DataType, - (オーディオ/ビデオ) サイズ, - (データ バッファのサイズ) データ バッファ - (データはタイプによって異なります) }

'DataType' と 'Size' は常に一定のサイズです。クライアント側で「DataType」と「Size」を取得し、対応する送信データ (Adio/Video) の指定されたサイズを読み取ります。

于 2013-07-11T06:11:06.983 に答える
0

頭のてっぺんから何かを作っているだけです。次のような「パケット」を送信します。

1 byte - packet type (audio or video)
2 bytes - data length
(whatever else you need)
|
|  (raw data)
|

したがって、相手側でこれらのパケットの 1 つを取得するたびに、読み取るデータの量と、次のパケットの開始位置を正確に把握できます。

[430 byte audio L packet]
[430 byte audio R packet]
[1000 byte video packet]
[20 byte control packet]
[2000 byte video packet]
...

しかし、なぜ車輪を再発明するのでしょうか? これらのことを行うためのプロトコルはすでにあります。

于 2013-07-11T06:14:56.877 に答える