rtmfp cppダウンロードrtmfp cppソースコードダウンロード

rtmfp cpp

その他のカテゴリー

Version 1.5.1

ダウンロード

セキュアリアルタイムメディアフロープロトコルライブラリ

これは、RFC 7016で説明されているように、安全なリアルタイムメディアフロープロトコル（RTMFP）のC ++（11）の実装です。

ライブラリには、Simple select()ベースの実行ループなど、サンプルプラットフォームアダプターやその他のユーティリティが含まれていますが、これらを使用する必要はありません。プロトコルの実装は、ホストプログラム環境に適応できることを目的としています。

ライブラリは、クライアント、サーバー、およびP2Pアプリケーションを対象としています。 P2Pの導入と負荷分散をサポートするために、必要なヘルパーとコールバックフックが含まれています。

testディレクトリには、ユニットテストと例が含まれています。特に注目すべきは、シンプルなRTMFPおよびRTMPライブメディアサーバーであるtcserverです。 tcrelay 、rtmfp rtmpリレー/プロキシ。 redirector 、単純なロードバランサー。

使い方

最も完全なAPIドキュメントは、現在rtmfp.hppヘッダーファイルにあります。

アプリケーションは、 IPlatformAdapterとICryptoAdapterをインスタンス化し、次にcom::zenomt::rtmfp::RTMFP （これらのアダプターが必要です）をインスタンス化します。通常、プラットフォームアダプターは、インスタンスのプラットフォームメソッド（ howLongToSleep()やonReceivePacket()など）を呼び出すことができるように、新しいRTMFPインスタンスを通知する必要があります。

プラットフォームはRTMFP::addInterface()を呼び出すことにより、少なくとも1つのインターフェイスを追加します。

アプリケーションはRTMFP::openFlow()およびFlow::openFlowを使用して、新規または現在のエンドポイントへの送信フローを開くことができ、 RecvFlow::openReturnFlow()で関連付けられたリターンフローを開くことができます。

アプリケーションは、 RTMFP （むき出しの流入用）またはSendFlow S（関連するリターンフロー用）にonRecvFlowコールバックを設定することにより、新しいフローを受け入れることができます。

アプリケーションはSendFlow::write()を使用してファーピアにメッセージを送信し、 RecvFlow sでのonMessageコールバックを設定することにより、ファーピアからメッセージを受信できます。メッセージごとに、またはSendFlow::write()によって返されたWriteReceiptを使用した任意のアプリケーションロジックによって開始または配信されない場合、メッセージは期限切れになり、放棄される可能性があります。アプリケーションは、メッセージが配信または放棄されたときにコールバックによって通知できます。

SendFlow Sセットは、 PRI_PRIORITY 、 PRI_IMMEDIATE 、 PRI_FLASH 、またはPRI_FLASHOVERRIDEに優先/優先順位に設定されています。時間の重要なメッセージを送信すると、混雑制御に影響します。

それが完了すると、アプリケーションはRTMFP整然とした方法で、または突然シャットダウンできます。

スレッドモデル

プロトコルの実装はシングルスレッドされており、ロック/ミューテックスはありません。 APIへのすべての呼び出しは、たとえば、すべてが同じスレッドまたはループ様コンストラクトにあることにより、外部的に同期する必要があります。これは、現代のCPUでロックが非常に高価になる可能性があるため、携帯性とパフォーマンスを向上させるために行われました。同期は、プラットフォームアダプターのperform方法によって抽出され、必要に応じて他のコア/スレッドに高価または時間のかかる操作をオフロードできるようにします。

プラットフォームアダプター

プロトコルの実装は、オペレーティングシステムのUDPソケット、クロック、実行ループ、ロック、またはスレッドと直接相互作用しません。これらの相互作用は、ホストプログラムによって提供されるプラットフォームアダプターに抽出されます。

プラットフォームアダプターはcom::zenomt::rtmfp::IPlatformAdapterの具体的な実装であり、「プラットフォームアダプターが使用する」セクションでRTMFPパブリックインスタンスメソッドを呼び出します。アダプターは、現在の時刻、読み取りと書き込みをソケット、タイミング、同期を提供します。

ライブラリは、純粋なシングルスレッドアプリケーション用のRunLoop Sで実行される2つの例プラットフォームPosixPlatformAdapterと、CPU集約型のパブリックキー暗号化をワーカースレッドにオフロードできるようにするために、 PerformerPosixPlatformAdapter提供します。これらのプラットフォームアダプターは、UNIXのようなオペレーティングシステム上の多くのアプリケーションに適している必要があり、ホストアプリケーション用のシングルスレッドおよびマルチスレッドプラットフォームアダプターの作成方法の例として機能する必要があります。

プラットフォームアダプターのインターフェイスがUDPソケットになる必要はありません。たとえば、インターフェイスは靴下であるか、プロキシ、トンネル、またはネットワークシミュレーターを回すことができます。

Runloopとパフォーマー

UNIXのようなオペレーティングシステムの場合、このライブラリは、多くのソケットベースのアプリケーションに適したシンプルなselect()ベースの実行ループを提供します。また、多くのソケットを処理するためにselect()よりも優れたLinux用の単純なepollベースの実行ループも含まれています。 PreferredRunLoopエイリアスを使用して、ターゲットOSのコンパイル時間に利用可能な最適なバリアントを自動的に選択します。

Performer実行するループに接続して、任意のスレッドからの実行ループと同期したタスクを呼び出すことができます。 Performer Sは、 PerformerPosixPlatformAdapterで使用されます。

Windows

Microsoft Windowsは、公式にサポートされているプラットフォームではありません。ただし、コアライブラリ（プラットフォームアダプター、実行中のループ、 Performerを除く）は、Windowsの上に構築され、そのプラットフォームのコアのメンテナンスは、コミュニティが許可する時間と支援として試みられます。 Windowsのコアライブラリに問題がある場合は、問題を開きます。

このライブラリをWindowsで使用するには、適切なプラットフォームアダプターを提供する必要があります。

メンテナーに連絡するか、問題を開いて、Windows Platformアダプターへのリンクをリクエストして、このドキュメントに追加するようにしてください。

暗号化アダプター

RFC 7016は、アプリケーションのニーズに応じてRTMFP通信を保護するための一般化されたフレームワークを説明し、暗号化の詳細を暗号化プロファイルに残します。このライブラリは、特定の暗号化プロファイルにアプリケーションをロックせず、多くの潜在的なプロファイルをサポートするために書かれています。暗号化プロファイルは、インスタンス化時にRTMFPに提供されるコンクリートのICryptoAdapterによって実装されます。

RTMFPのほとんどのアプリケーションは、RFC 7425で説明されているフラッシュ通信に暗号化プロファイルを使用します。これはFlashCryptoAdapterによって提供されます。このアダプターは抽象的であり、必要な暗号化プリミティブの具体的な実装を提供するためにサブクラス化する必要があることに注意してください。 OpenSSLを使用した具体的な実装は、 FlashCryptoAdapter_OpenSSLによって提供されます。これは、他の暗号化ライブラリの使用方法の例としても機能します。 OpenSSLを持っていない場合、または使用したくない場合は、 make Variableを定義することにより、このモジュールの構築をWITHOUT_OPENSSLできます。 OpenSSLがコンパイラのデフォルトの内容とリンカー検索パスの外にインストールされている場合、適切な指示を使用して変数をOPENSSL_INCLUDEDIRおよびOPENSSL_LIBDIR makeを定義できます（例についてはMakefile参照）。

FlashCryptoAdapterのOpenSSL実装は、Diffie-Hellman Key契約のために、4096ビットインターネットキーエクスチェンジ（IKE）グループ16、2048ビットIKEグループ14、および1024ビットIKEグループ2を実装しています。フラッシュ通信暗号化プロファイルのすべての実装は、少なくともグループ2を実装する必要があります。グループ14も実装しています。この実装は、最も強力な共通グループを好みます。

RTMFPはフラッシュプラットフォーム通信に限定されないことに注意してください。このライブラリは、テストと評価に適したPlainCryptoAdapterを提供します。実際の暗号化（およびそのcryptoHash256()およびpseudoRandomBytes()の方法は特に弱いため、それはオープンインターネットでの生産の使用には適していません。しないでください。

遅延ベースの混雑検出

バッファーブロート（ネットワークでの過度のバッファリングとキューイング）は、エンドツーエンドの遅延を引き起こす可能性があり、リアルタイムアプリケーションの容認できないパフォーマンスをもたらします。残念ながら、この問題の最良の解決策（明示的な混雑通知を備えたアクティブキュー管理）は、現時点ではインターネットに普遍的に展開されていません。

通常の輻輳シグナル（損失および明示的な混雑通知）に加えて、このライブラリは、往復時間（RTT）の増加からのセッションでの可能性のある混雑をオプションで推測できます。この機能を有効にするには、 Flow::setSessionCongestionDelay()を使用して、ベースラインRTTより上に追加の遅延を設定して、混雑の兆候として解釈されます。デフォルト値はINFINITYです。この機能には、 0.1秒の追加遅延の値が提案されています。

ベースラインRTTは、過去3分間で観察される最小RTTです。ベースラインRTT観測ウィンドウがクリアされ、次の状況でリセットされます。

タイムアウト（総損失または送信のデータなし）;
輻輳ウィンドウが最小値に当てはまる場合、これは実際に私たちの過失ではない永続的な推測輻輳の後に発生する可能性があります（パスへの変更や競合するトラフィックから）;
遠端のアドレスが変更された場合。
私たちのアドレスが変更された可能性がある場合（遠端からのアドレス変更検証プローブである可能性のある空でないpingの受領から推測されます）。

時々、輻輳ウィンドウのかなりの部分が使用されている場合、新しいベースラインRTTのパスをプローブするために、輻輳ウィンドウが一時的に縮小されます（私たち自身の送信がベースラインをマスキングしている場合）。これがジッターを引き起こす可能性があることに注意してください。

平滑化されたRTTがベースラインの上にあることが観察され、構成されたCongestionDelayが（そして少なくとも30ミリ秒）、これは輻輳の兆候であると想定されています。混雑コントローラーは、これが損失であるかのように応答します。

すべてのエンドツーエンド遅延ベースのものと同様に、この輻輳検出スキームは不完全であり、以下を含むケースによって引き起こされる偽陽性信号の影響を受けます。

このセッションのもう一方の端からのデータによって引き起こされる追加の遅延。
どちらの方向にもボトルネックを介して競合する遅延非感受性キューに浸る送信によって引き起こされる追加の遅延。
RTT測定を遅らせるパスの戻り方向への変更。

そのため、この機能はすべてのユースケースに示されていない場合があります。誤った陽性のうっ血信号がありそうにない場合にのみ、この機能を有効にするように注意する必要があります。誤検知は、伝送の飢vを引き起こす可能性があります。

この機能は、低い余分な遅延バックグラウンドトランスポート（LEDBAT）、マルチメディア（Scream）のセルフクロックレート適応、およびGoogleのBBR混雑制御アルゴリズムに触発されています。

明示的な混雑通知

RTMFPのこの実装は、明示的な輻輳通知（ECN）のサポートを追加します。受信したECNコードポイントのカウントをECN送信者に送り返すために、受信機に新しい実験チャンク「ECNレポート」（タイプ0xec ）を追加します。 RTMFPは、ECNの有能な輸送コードポイント（ ECT(0) 、 ECT(1) 、またはECN-CE）でマークされたそのピアとのS_OPENセッションで少なくとも1つの有効なパケットを受け取っていない限り、PEERにECN-CEレポートを送信してはなりません。

ECN対応であるRTMFPレシーバーは、ECNレポートをECN対応ピアに送信します。 ECNレポートは、確認を含むパケットの最初の確認チャンクの前に組み立てられる必要があります（レポートの切り捨てを避けるため）。 ECN送信者が、近距離および遠いインターフェイス、パス、およびレシーバーサポートECNを検出できるために、ECN対応の受信機は、ECN対応の輸送コードポイントでマークされたパケットがECNレポートが送信された場合、またはレポートがまだ送信されていない場合のいずれかで、eCN対応のパケットにECNレポートを送信する必要があります。

RTMFP送信者は、受信者がECN対応ではないと判断した場合、ECN対応の輸送コードポイントでパケットのマークを停止する必要があります（たとえば、送信者がピアとのオープンセッション中にマークされたパケットで送信されたユーザーデータの承認とともに少なくとも1つのECNレポートを受け取っていない場合）。

ECN対応のRTMFPレシーバーはECN-CEでマークされた受信したパケットの数の少なくともカウントを保持します。エンドポイントは、ECNレポートチャンクで現在のカウンターの8ビットを同業者に送信します。

この実装はECT(0)を送信します。混雑コントローラーはECN-CE-countの増加に損失であるかのように応答します。 ECT(0)は、ユーザーデータを含むパケットにのみ送信されます。

明示的な混雑通知レポートチャンク（ECNレポート）

 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0xec     |               1               | ECN-CE-count  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

struct ecnReportChunkPayload_t
{
    uint8_t congestionExperiencedCountMod256; // ECN-CE-count
} :8;