7

バックグラウンド

リモート コンピューターのデスクトップのライブ フィードをアプリケーションにストリーミングしようとしています。これを行うために、接続指向 (TCP) ソケットを使用して、クライアントのコンピューターのフレームをキャプチャし、それをサーバーに送信しています。

私の研究

100 ミリ秒 (10 FPS) ごとにフレーム (スクリーンショット) を送信しています。各フレームは約 145kb です。つまり、1 秒あたり 1450kb を送信する必要があります (これは 1.4 メガバイト、1 秒あたり 11 メガビットに相当します)。

私のインターネットの最大ダウンロード速度は毎秒 0.32 メガビットです。毎秒 11 メガビットのデータを送信する必要があるため、これは私のインターネットが必要な速度よりも 10.6 メガビット遅いことを意味します。したがって、私の計算では、デスクトップを効率的にストリーミングするには、各フレームを約 4.5kb (4608b + 20b TCP ヘッダー) にする必要があります。これは、デスクトップの更新された部分のみを送信し、ビットマップを圧縮する場合でも、現在のシステムでは現実的に不可能です。 .

質問

システムがアップロード速度によって正確に制限されているかどうかはわかりません。4.5kb はとてつもなく小さいサイズだからだと思います。同様のソフトウェア (Teamviewer、Join.me、Skype などのソフトウェア) を使用して、デスクトップを完全にスムーズにストリーミングできます。これらのソフトウェア パッケージは、私よりもはるかにインテリジェントなプロトコルを使用します (ここで良い質問です)。各フレーム/デスクトップの更新。

したがって、私の質問は最終的には次のとおりです。私の計算はまったく正確ですか?なぜですか? ここでの目的は、各フレームの適切なサイズを決定することです。これにより、そのサイズに到達し、さまざまな速度の接続の品質/間隔を計算できるようになります。もちろん、私の状況に役立つコメント/回答に興味がありますが、私が受け入れる回答は、私の実際の質問に回答するものになります.

4

2 に答える 2

1

あなたの計算は少し混乱するので、最初にビットとバイトを混同しないでください。

第二に、送信しているオブジェクトのサイズだけを見ていて、パケット自体を忘れています。サイズが少し増え、耐える TCP 遅延を忘れないでください。ネットワークがトラフィックの送信にこれほど敏感である場合は、アップグレードするか、より良い圧縮を使用することをお勧めします.

結論として、ネットワークでサポートされる帯域幅は、必要なパスに沿って最小の帯域幅を持つ部分に等しいと常に言います。

例: 10M => 100K => 1M ==> 10M (ここでは最大速度は 100K です)

于 2013-03-07T14:43:44.813 に答える
0

TCP クライアントの最大送信速度は、クライアント コンピューターのアップロード速度によって正確に制限されますか?

無意味な質問です。どの接続でも、それらは同じものであり、どちらもそれらの間の最も遅いリンクの速度によって決定されます。

于 2013-03-07T23:43:35.617 に答える