rtmfp cpp下載rtmfp cpp源代碼下載

rtmfp cpp

其他類別

Version 1.5.1

下載

保護實時媒體流程協議庫

這是RFC 7016中所述的安全實時媒體流程協議（RTMFP）的C ++（11）實現。

該庫包括示例平台適配器和其他實用程序，例如基於簡單的select()的運行循環，但不需要使用這些循環。協議實施旨在適應任何主機程序環境。

該庫適用於客戶，服務器和P2P應用程序。它包括必要的助手和回調鉤，以支持P2P簡介和負載平衡。

test目錄包括單位測試和示例。特別值得注意的是tcserver ，一個簡單的RTMFP和RTMP Live Media Server； tcrelay ，RTMFP↔︎rtmp繼電器/代理；和redirector ，一個簡單的負載平衡器。

如何使用

最完整的API文檔當前在rtmfp.hpp標頭文件中。

應用程序將實例化IPlatformAdapter和ICryptoAdapter ，然後是com::zenomt::rtmfp::RTMFP （需要這些適配器）。通常，需要告知平台適配器新的RTMFP實例，因此它可以調用實例的平台方法（例如howLongToSleep()和onReceivePacket() ）。

該平台將通過調用RTMFP::addInterface()添加至少一個接口。

該應用程序可以使用RTMFP::openFlow()和Flow::openFlow打開向新的或當前端點發送流量，並且可以使用RecvFlow::openReturnFlow()打開關聯的返回流。

該應用程序可以通過在RTMFP上設置onRecvFlow回調（用於裸機流）或SendFlow S（對於關聯的返回流）上來接受新的流。

該應用程序可以通過SendFlow::write()將消息發送給遙遠的同行，並通過在RecvFlow上設置onMessage回調”來接收來自遙遠同行的消息。如果不是由每人截止日期開始或傳遞的消息，或使用SendFlow::write()返回的WriteReceipt s，消息可能會過期並被放棄。當消息傳遞或放棄時，可以通過回調通知該應用程序。

SendFlow s設置為優先/優先級PRI_PRIORITY ， PRI_IMMEDIATE ， PRI_FLASH或PRI_FLASHOVERRIDE被認為是時間至關重要。發送時間關鍵信息會影響擁塞控制。

完成後，應用程序可以有序或突然關閉RTMFP 。

線程模型

協議實現是單線讀取的，沒有鎖/靜音。所有對其API的調用都必須在外部同步，例如，所有呼叫都在同一線程或類似於環形的構造中。這是為了提高便攜性和性能，因為鎖定在現代CPU上可能非常昂貴。平台適配器的perform方法抽象了同步，如果需要，可以將某些昂貴或耗時的操作卸載到其他內核/線程（如果需要）。

平台適配器

協議實現未直接與操作系統的UDP插座，時鐘，運行循環，鎖或線程進行交互。這些交互被抽象成主機程序提供的平台適配器。

平台適配器將是com::zenomt::rtmfp::IPlatformAdapter的具體實現，該實現稱為“平台適配器使用”部分中的RTMFP公共實例方法。適配器提供了當前時間，讀寫和寫作，以插入插座，時機和同步。

該庫提供了兩個示例平台適配器，這些適配器在RunLoop s： PosixPlatformAdapter中運行，用於純單線程應用程序，以及PerformerPosixPlatformAdapter ，以允許將CPU密集型公共密鑰密碼學卸載到工作線程中。這些平台適配器應適用於類似Unix的操作系統上的許多應用程序，並應作為如何編寫單讀和多線程平台適配器的示例。

不需要平台適配器的接口是UDP插座。例如，接口可以是襪子或轉動代理，隧道或網絡模擬器。

Runloop和表演者

對於類似於Unix的操作系統，該庫提供了一個簡單的基於select()的運行循環，適用於許多基於插座的應用程序。它還包括一個簡單的基於epoll的Linux運行循環，該循環比select()來處理許多插座。使用PreferredRunLoop別名自動選擇目標操作系統時的編譯時可用的最佳變體。

可以將Performer連接到運行循環中，以啟用內部調用任務/與任何線程的運行循環同步。 Performer S與PerformerPosixPlatformAdapter一起使用。

視窗

Microsoft Windows不是正式支持的平台。但是，核心庫（不包括平台適配器，運行循環和Performer ）應在Windows上構建，並且將嘗試將該平台的核心維護作為時間和幫助。如果Windows上的核心庫存在問題，請打開問題。

要在Windows上使用此庫，您將需要提供適當的平台適配器。

請聯繫維護人員或打開問題，要求在此文檔中添加到Windows平台適配器的鏈接。

加密適配器

RFC 7016描述了一個通用框架，該框架是根據應用程序的需求確保RTMFP通信的，並將加密詳細信息留在加密概況中。該庫不會將其應用程序鎖定到任何特定的密碼概要文件中，並編寫以支持許多潛在的配置文件。加密概況由提供給RTMFP實例化的混凝土ICryptoAdapter實現。

RTMFP的大多數應用程序都將使用加密概況進行RFC 7425中描述的閃存通信。這是由FlashCryptoAdapter提供的。請注意，該適配器是抽象的，必須分類以提供所需的加密原始圖的具體實現。 FlashCryptoAdapter_OpenSSL提供了使用OpenSL的具體實現，該實現也可以作為如何使用其他密碼庫的示例。如果您沒有OpenSSL或不想使用它，則可以通過在WITHOUT_OPENSSL情況下make變量來抑制構建此模塊。如果您的OPENSL安裝在編譯器的默認包含和鏈接搜索路徑之外，則可以定義make變量OPENSSL_INCLUDEDIR和OPENSSL_LIBDIR並帶有適當的指令（有關示例，請參見Makefile ）。

FlashCryptoAdapter的OpenSSL實施4096位Internet密鑰交換（IKE）組16、2048-BIT IKE組14和1024-BIT IKE組2 for Diffie-Hellman密鑰協議。 Flash通信加密配置文件的所有實現都必須至少實施第2組；一些人還實施了第14組。此實施更喜歡最強大的共同組。

請注意，RTMFP不限於閃存平台通信。該庫提供了適合測試和評估的PlainCryptoAdapter 。由於它不提供實際的加密術（及其cryptoHash256()和pseudoRandomBytes()方法特別弱），因此它不適合在開放互聯網中生產使用。不。

基於延遲的擁塞檢測

BufferBloat（網絡中的過度緩沖和排隊）可能會導致高端到端延遲，從而導致實時應用程序的性能不可接受。不幸的是，目前尚未普遍部署此問題（帶有明確擁塞通知的主動隊列管理）的最佳解決方案。

除了正常的交通擁堵信號（損失和明確的擁塞通知）外，該圖書館還可以選擇從往返時間增加（RTT）中推斷出會議上的擁塞。要啟用此功能，請使用Flow::setSessionCongestionDelay()設置高於基線RTT的額外延遲，以解釋為交通擁堵的指示。默認值是INFINITY 。對於此功能，建議提出0.1秒的額外延遲值。

基線RTT是過去三分鐘內最多觀察到的最小RTT。在以下情況下清除基線RTT觀測窗口並重置：

超時（來自總損失或無數據發送）；
如果擁塞窗口降至最低價值，這可能是在持續推斷的擁塞後發生的，這實際上不是我們的錯（例如從變化到路徑或競爭流量）；
如果遠端的地址發生了變化；
如果我們的地址可能發生了變化（從收到的非空Ping中推斷，這可能是地址更改驗證探測器的探測）。

不時地使用擁塞窗口的很大一部分，將暫時減少擁塞窗口，以探測新的基線RTT的路徑（如果我們自己的發送是掩蓋了基線）。請注意，這可能會導致抖動。

如果觀察到平滑的RTT高於基線以及配置的CongestionDelay （並且也至少為30ms），則假定這是擁塞的指示。擁塞控制者對此做出回應，好像是損失。

與所有基於端到端的延遲延遲一樣，這種擁堵檢測計劃是不完善的，並且受到案件造成的假信號的約束：

由本課程另一端的數據引起的其他延遲；
由延遲不敏感的隊列填充傳輸引起的額外延遲，沿任一方向通過瓶頸競爭；
更改延遲RTT測量的路徑的返回方向。

因此，對於所有用例，可能不會指示此功能。只有在不太可能的誤報充血信號（例如通過專用的瓶頸）實質上單向媒體傳輸時，才應注意才能啟用此功能。誤報會導致傳播飢餓。

此功能的靈感來自較低的額外延遲背景傳輸（LEDBAT），多媒體（Scream）的自鎖速率適應和Google的BBR擁塞控制算法。

明確的擁塞通知

RTMFP的實施增加了對明確的擁塞通知（ECN）的支持。它添加了一個新的實驗塊“ ECN報告”（類型為0xec ），以使接收器將接收到的ECN CodePoint的計數發送回ECN發件人。 RTMFP不得將ECN報告發送給其同行，除非它在其S_OPEN會話中至少收到了一個有效的數據包，該數據包與具有ECN具有ECN的運輸代碼點（ ECT(0) ， ECT(1)或ECN-CE ）標記的同行。

具有ECN能力的RTMFP接收器將ECN報告發送給具有ECN的同伴。 ECN報告應在包含確認的任何數據包中的第一個確認塊之前組裝（以避免對報告的截斷）。為了使ECN發件人能夠檢測到近距離接口，路徑和接收器支持ECN，具有ECN能力的接收器應在任何包含確認的數據包中發送ECN報告，如果自從上次發送了ECN報告以來已收到的任何包含ECN能夠運輸代碼點的數據包，或者尚未發送ECN報告。

如果RTMFP發件人確定接收器不可ECN的能力，則必須停止使用ECN能夠運輸代碼點標記數據包（例如，如果發送者尚未收到至少一份ECN報告以及在與同伴開放期間在標記數據包中發送的用戶數據的確認書）。

具有ECN能力的RTMFP接收器至少保留了帶有ECN-CE數據包數量的計數。端點將當前計數器的低8位發送給其ECN報告中的同行。

此實現發送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;