開発では、クライアント側でFlash Player 10.1、サーバー側でAdobe Cirrusによって実装されたRTMFPプロトコルを使用します。
これにより、2つの理由でビデオを一度に再生する際の遅延が減少します。 一方では、北への直接的な要求はあまり頻繁に行われず、サーバーが他の要求を処理して応答することが容易になります。 一方、システムは最大効率の考慮に基づいてパートナーを選択するため、「隣接」からデータを受信する速度はデータセンターのサーバーよりも高速になることがよくあります。
ビデオプレーヤーは、一度に視聴されているビデオのみを配信できます。ダウンロードされてまだメモリに残っている部分のみを配信できます。 同時に、RAMを使いすぎないように、バッファサイズは64 MBを超えることはできません。 理論的には、P2Pモードを有効にするには、2人のユーザーが同時にビデオを見るだけで十分です。 ただし、数十人のユーザーが同時に視聴するビデオにのみお勧めします（上記のように、VKontakteの場合、そのようなビデオはアクティブに視聴されるビデオの約15〜20％を占めます）。 p2pを使用しても目に見える結果が得られないビデオを再生する場合、プレーヤーは標準ダウンロードに切り替わります。
クライアントの識別には、Adobe Cirrusサーバーによって発行されたキーのみが使用され、そこからIPアドレスもユーザーuidも復元できません。
技術的な詳細
前述のように、同じ動画を（同じ解像度で）視聴する別のユーザーグループに統合するために、RTMFPプロトコルとやり取りするAdobeのCirrusサービスが現在使用されています。 対応するNetGroupクラスのサポートは、フラッシュプレーヤーバージョン10.1でのみ登場しました。したがって、10番目のバージョンプレーヤーを持つユーザーには、P2Pを使用するオファーは表示されません。
ユーザー間の同じビデオの部分間の交換を整理するために、ファイルは64 Kbのチャンクに分割されます。 各チャンクは主に近隣のピアから要求されます（プロセス全体はフラッシュプレーヤーとCirrusサーバーによって内部的に規制されます）。応答がない場合は、数秒以内にVkontakteビデオサーバーに直接要求が行われます-データはチャンクに分割され、他のユーザーに配信されます。
ロードされたチャンクを出力するには、NetStreamクラスのいわゆる「データ生成モード」が使用されます。 残念ながら、現在Vkontakteビデオの保存に使用されているMP4形式をサポートしていないため、MP4からFLVへのコンテナは、チャンクから収集されたビデオファイルからオンザフライで変更されます。
再生の開始点に関係なく、再生されたファイルを同一に保つ必要があるため、任意の場所から再生する場合、サーバー側でキーフレームの作成を中止することにしました。 選択した瞬間に最も近いフレームの選択もクライアントによって行われるようになりました。これにより、ビデオを巻き戻す際の遅延がさらに減少します。
小計
現在の段階での主な結果は、遅延の顕著な減少です。
- 多数のユーザーが同時にダウンロードした人気のあるビデオを再生する場合。
- 任意の場所からビデオを再生するとき。