6

私のアプリケーションは、非同期 HttpWebRequest リクエストを使用して多数のビデオ フレームをプリフェッチします。したがって、100 フレームがある場合、プリフェッチャーは 100 フレームすべてを一度に非同期で要求し、受信時に処理します。つまり、一度に 100 の非同期呼び出しを行います。これにより、ネットワーク カードが飽和する可能性がありますが、問題ありません。ネットワーク帯域幅を最大化したい。

ただし、このプリフェッチが行われている間、ユーザーはフレームの 1 つを表示したい場合があります。フレーム 56 を表示したいとします。問題は、フレーム 1 ~ 100 が既に要求されており、パイプ内にあるため、フレーム 56 の要求が応答を取得するのに時間がかかる場合があることです。

非同期リクエストが作成された後に、それらの優先度を再設定する方法があればいいのですが。そして、ユーザー要求をキューの先頭にプッシュします。

これができない場合は、フレームをバッチでリクエストする必要があると思います。これにより、バッチ間でユーザーリクエストを滑り込ませ、タイムアウトを回避できます。

これを適切に設計する方法についてのアイデアは非常に高く評価されます。

4

2 に答える 2

1

これはプログラミングの問題ではなく、プロトコルの問題です。ワイヤーを飽和させる貪欲なプロトコルを使用すると、従来のプロトコルを使用する独自のオプションでさえ効果的に閉鎖されます。

帯域幅の一部を 2 番目のチャネル用に予約した場合、その 2 番目のチャネルをバッチ フレームの代わりに個々のフレームに使用できます。飽和状態の NIC が存在する場合に 2 番目のチャネルのフレームに優先順位を付けるには、サービスの品質またはトラフィックに優先順位を付けるための他のリンク層が必要です。

しかし、私たちは先を行っています。正常に動作する機能的なアプリケーションが必要な場合は、プロトコルの専門家からのアドバイスを受けて、座って実際のプロトコルを定義する必要があります: NIC、スイッチ、プロトコル、パケット サイズ、再試行など。プログラミングの問題。

于 2011-05-13T03:28:55.010 に答える
0

ああ、優先キューまたはヒープを使用して、フレームの「パケット」を処理します。タイムアウトは必要なく、速度も必要なので、フレーム パケット (サイズは 2 の累乗) を作成し、それらに優先度を関連付けます (要求されていない場合は 0、ユーザーが要求した場合は 1 など)。そうすれば、優先度の最も高いパケット (ユーザーが要求したもの) が常にキューの先頭またはヒープの先頭になります。

于 2011-05-13T03:18:22.800 に答える