rtmfp cpp
Version 1.5.1
이것은 RFC 7016에 설명 된대로 보안 실시간 미디어 흐름 프로토콜 (RTMFP)의 C ++ (11) 구현입니다.
라이브러리에는 샘플 플랫폼 어댑터 및 간단한 select() 기반 런 루프와 같은 기타 유틸리티가 포함되어 있지만 사용할 필요는 없습니다. 프로토콜 구현은 모든 호스트 프로그램 환경에 적응하기위한 것입니다.
라이브러리는 클라이언트, 서버 및 P2P 응용 프로그램을위한 것입니다. P2P 소개 및로드 밸런싱을 지원하기 위해 필요한 도우미 및 콜백 후크가 포함되어 있습니다.
test 디렉토리에는 단위 테스트 및 예제가 포함되어 있습니다. 특별한 참고 사항은 tcserver , 간단한 RTMFP 및 RTMP 라이브 미디어 서버입니다. tcrelay , RTMFP ↔︎ RTMP 릴레이/프록시; 및 간단한로드 밸런서 인 redirector .
가장 완전한 API 문서는 현재 rtmfp.hpp 헤더 파일에 있습니다.
응용 프로그램은 IPlatformAdapter 와 ICryptoAdapter 인스턴스화 한 다음 com::zenomt::rtmfp::RTMFP (이 어댑터가 필요합니다)를 인스턴스화합니다. 일반적으로 플랫폼 어댑터는 인스턴스의 플랫폼 메소드 (예 : howLongToSleep() 및 onReceivePacket() )을 호출 할 수 있도록 새로운 RTMFP 인스턴스에 대해 알려야합니다.
플랫폼은 RTMFP::addInterface() 호출하여 하나 이상의 인터페이스를 추가합니다.
응용 프로그램은 RTMFP::openFlow() 및 Flow::openFlow 사용하여 새 또는 현재 엔드 포인트로 전송 흐름을 열 수 있으며 RecvFlow::openReturnFlow() 사용하여 관련 반환 흐름을 열 수 있습니다.
응용 프로그램은 RTMFP (Bare Incoming Flows) 또는 SendFlow S (관련 반환 흐름)에서 onRecvFlow 콜백을 설정하여 새로운 흐름을 수락 할 수 있습니다.
응용 프로그램은 SendFlow::write() 사용하여 먼 동료에게 메시지를 보낼 수 있으며 RecvFlow s에서 onMessage 콜백을 설정하여 먼 동료로부터 메시지를받을 수 있습니다. Message 마감일 또는 SendFlow::write() 에 의해 반환 된 WriteReceipt S를 사용하여 임의의 응용 프로그램 논리에 의해 시작되거나 전달되지 않으면 메시지가 만료되고 포기 될 수 있습니다. 메시지가 전달되거나 포기되면 콜백으로 응용 프로그램에 알릴 수 있습니다.
SendFlow s는 우선 순위/ PRI_PRIORITY , PRI_IMMEDIATE , PRI_FLASH 또는 PRI_FLASHOVERRIDE 로 설정된 SendFlow가 시간 중요한 것으로 간주됩니다. 시간 보내기 중요한 메시지는 정체 제어에 영향을 미칩니다.
완료되면 응용 프로그램은 순서대로 또는 갑자기 RTMFP 종료 할 수 있습니다.
프로토콜 구현은 단일 스레드이며 잠금/음소거가 없습니다. API에 대한 모든 호출은 예를 들어 동일한 스레드 또는 런 루프와 같은 구성에 의해 외부 동기화되어야합니다. 이는 최신 CPU에서 잠금이 매우 비쌀 수 있기 때문에 이식성과 성능을 향상시키기 위해 수행되었습니다. 동기화는 플랫폼 어댑터의 perform 에 의해 추상화되어 원하는 경우 비싸거나 시간이 많이 걸리는 작업을 오프로드 할 수 있습니다.
프로토콜 구현은 운영 체제의 UDP 소켓, 클럭, 실행 루프, 잠금 또는 스레드와 직접 상호 작용하지 않습니다. 이러한 상호 작용은 호스트 프로그램에서 제공하는 플랫폼 어댑터 로 추상화됩니다.
플랫폼 어댑터는 com::zenomt::rtmfp::IPlatformAdapter 의 구체적인 구현이 될 것이며, 이는 플랫폼 어댑터에서 사용한 RTMFP 공개 인스턴스 메소드를 호출합니다. 어댑터는 현재 시간, 소켓, 타이밍 및 동기화에 대한 읽기 및 쓰기를 제공합니다.
이 라이브러리는 RunLoop S에서 실행되는 두 가지 예제 플랫폼 어댑터 : 순수한 단일 스레드 애플리케이션을위한 PosixPlatformAdapter 와 CPU- 집약적 인 공개 키 암호화를 작업자 스레드에 오프로드 할 수 있도록 PerformerPosixPlatformAdapter 제공합니다. 이 플랫폼 어댑터는 UNIX와 같은 운영 체제의 많은 응용 프로그램에 적합해야하며 호스트 애플리케이션을 위해 단일 스레드 및 다중 스레드 플랫폼 어댑터를 작성하는 방법의 예가되어야합니다.
플랫폼 어댑터의 인터페이스가 UDP 소켓이 될 필요는 없습니다. 예를 들어, 인터페이스는 양말 또는 회전 프록시, 터널 또는 네트워크 시뮬레이터 일 수 있습니다.
UNIX와 같은 운영 체제의 경우이 라이브러리는 많은 소켓 기반 애플리케이션에 적합한 간단한 select() 기반 런 루프를 제공합니다. 또한 많은 소켓을 처리하기 위해 select() 보다 더 잘 확장되는 Linux 용 간단한 epoll 기반 런 루프가 포함되어 있습니다. PreferredRunLoop 별칭을 사용하여 대상 OS의 컴파일 시간에 사용 가능한 최고의 변형을 자동으로 선택하십시오.
Performer 실행 루프에 연결하여 모든 스레드에서 실행 루프와 내부 작업을 호출/동기화 할 수 있습니다. Performer S는 PerformerPosixPlatformAdapter 와 함께 사용됩니다.
Microsoft Windows는 공식적으로 지원되는 플랫폼이 아닙니다. 그러나 핵심 라이브러리 (플랫폼 어댑터, 런 루프 및 Performer 제외)는 Windows를 구축해야하며 해당 플랫폼의 핵심 유지 보수는 커뮤니티가 허용하는 시간과 도움으로 시도됩니다. Windows의 핵심 라이브러리에 문제가있는 경우 문제를여십시오.
Windows 에서이 라이브러리를 사용하려면 적절한 플랫폼 어댑터를 제공해야합니다.
이 문서에서 여기에 추가 할 Windows 플랫폼 어댑터에 대한 링크를 요청하려면 관리자에게 문의하거나 문제를 열십시오.
RFC 7016은 응용 프로그램의 요구에 따라 RTMFP 통신을 보호하기위한 일반화 된 프레임 워크를 설명하고 암호화 세부 사항을 암호화 프로파일 에 남겨 둡니다. 이 라이브러리는 응용 프로그램을 특정 암호화 프로필에 고정시키지 않으며 많은 잠재적 인 프로파일을 지원하기 위해 작성되었습니다. 암호화 프로파일은 인스턴스화시 RTMFP 에 제공된 콘크리트 ICryptoAdapter 에 의해 구현됩니다.
RTMFP의 대부분의 응용 프로그램은 RFC 7425에 설명 된 플래시 통신에 암호화 프로파일을 사용합니다. 이는 FlashCryptoAdapter 에서 제공합니다. 이 어댑터는 추상적이며 필요한 암호화 프리미티브의 구체적인 구현을 제공하기 위해 서브 클래스를 제공해야합니다. OpenSSL을 사용한 구체적인 구현은 FlashCryptoAdapter_OpenSSL 에서 제공하며 다른 암호화 라이브러리를 사용하는 방법에 대한 예일 수도 있습니다. OpenSSL이 없거나 사용하고 싶지 않은 경우 WITHOUT_OPENSSL 없이 make 변수를 정의 하여이 모듈 빌딩을 억제 할 수 있습니다. OpenSSL이 컴파일러의 기본값 포함 및 링커 검색 경로 외부에 설치된 경우, 적절한 지침으로 변수 make OPENSSL_INCLUDEDIR 및 OPENSSL_LIBDIR 로 정의 할 수 있습니다 (예제는 Makefile 참조).
Diffie-Hellman 키 계약을 위해 FlashCryptoAdapter 의 OpenSSL 구현은 4096 비트 인터넷 키 교환 (IKE) 그룹 16, 2048 비트 IKE 그룹 14 및 1024 비트 IKE 그룹 2를 구현합니다. 플래시 통신 암호화 프로파일의 모든 구현은 최소한 그룹 2를 구현 해야합니다 . 일부는 또한 그룹 14를 구현합니다.이 구현은 가장 강력한 공통 그룹을 선호합니다.
RTMFP는 플래시 플랫폼 통신에만 국한되지 않습니다. 이 라이브러리는 테스트 및 평가에 적합한 PlainCryptoAdapter 제공합니다. 실제 암호화 (및 cryptoHash256() 및 pseudoRandomBytes() 방법은 특히 약하기 때문에 열린 인터넷에서 생산 사용에 적합하지 않기 때문입니다. 하지 않다.
BufferBloat (네트워크에서 과도한 버퍼링 및 대기열)는 높은 엔드 투 엔드 지연을 유발할 수있어 실시간 응용 프로그램에 대해 허용 할 수없는 성능을 초래할 수 있습니다. 불행히도,이 문제에 대한 최상의 솔루션 (명시 적 정체 알림을받은 활성 큐 관리)은 현재 인터넷에 보편적으로 배포되지 않습니다.
정체 정체 신호 (손실 및 명시 적 정체 알림) 외에도이 라이브러리는 선택적으로 왕복 시간 (RTT)의 증가로 인한 혼잡을 유추 할 수 있습니다. 이 기능을 가능하게하려면 Flow::setSessionCongestionDelay() 사용하여 정체의 표시로 해석 될 기준선 RTT 이상의 추가 지연을 설정하십시오. 기본값은 INFINITY 입니다. 이 기능에 대해 0.1 초의 추가 지연 값이 제안됩니다.
기준선 RTT는 지난 3 분 동안 관찰 된 최소 RTT입니다. 기준선 RTT 관측 창이 다음 상황에서 지워지고 재설정됩니다.
때때로 정체 창의 상당 부분을 사용하는 경우 새로운 기준 RTT의 경로를 조사하기 위해 정체 창의 상당 부분이 일시적으로 줄어 듭니다 (우리 자신의 전송이 기준선을 마스킹하는 경우). 이것은 지터를 유발할 수 있습니다.
스무딩 된 RTT가 기준선과 구성된 CongestionDelay (및 최소 30ms) 위에있는 것으로 관찰되면 이는 혼잡을 나타내는 것으로 가정합니다. 혼잡 컨트롤러는 마치 손실 인 것처럼 응답합니다.
모든 엔드 투 엔드 지연 기반 기반과 마찬가지로이 정체 탐지 체계는 불완전하며 다음을 포함한 경우에 의해 야기 된 잘못된 양의 신호가 적용됩니다.
따라서이 기능은 모든 사용 사례에 대해 표시되지 않을 수 있습니다. 전용 병목 현상을 통한 실질적으로 단방향 미디어 전송과 같이 잘못된 양의 혼잡 신호가 가능하지 않은 경우에만이 기능을 수행해야합니다. 잘못된 양성은 전염 기아를 유발할 수 있습니다.
이 기능은 LEDBAT (Low Extra Delay Background Transport), 멀티미디어 (SCEAL)에 대한 자체 클록 속도 적응 및 Google의 BBR 혼잡 제어 알고리즘에서 영감을 얻었습니다.
이 RTMFP 구현은 ECN (Explicit Congestion Notification)에 대한 지원을 추가합니다. 수신자가 수신 된 ECN 코드 포인트를 ECN 발신자에게 다시 보낼 수 있도록 새로운 실험 청크 "ECN Report"(유형 0xec )를 추가합니다. RTMFP는 S_OPEN 세션에서 ECN 유능 전송 코드 포인트 ( ECT(0) , ECT(1) 또는 ECN-CE )로 표시된 피어와 함께 S_OPEN 세션에서 적어도 하나의 유효한 패킷을받지 않는 한 ECN 보고서를 동료에게 보내지 않아야합니다 .
ECN 가능성 인 RTMFP 수신기는 ECN 보고서를 ECN 가능 피어에게 보냅니다. ECN 보고서는 승인이 포함 된 모든 패킷에서 첫 번째 승인 청크 전에 조립 되어야합니다 (보고서의 잘림을 피하기 위해). ECN 발신자가 근거리 및 원거리 인터페이스, 경로 및 수신자가 ECN을 지원하는지 여부를 감지 할 수 있도록 ECN 유능한 수신자는 ECN 유능한 전송 코드 포인트로 표시된 패킷이 마지막으로 전송 된 이후 또는 아직 보고서가 전송되지 않은 경우 승인을 포함하는 모든 패킷에서 ECN 보고서를 보내야 합니다 .
RTMFP 발신자는 수신기가 ECN 가능이없는 것으로 판단되면 ECN 유능한 전송 코드 포인트가있는 패킷 마킹을 중단 해야합니다 (예 : 발신자가 동료와의 공개 세션 동안 표시된 패킷으로 전송 된 사용자 데이터에 대한 승인을받지 않은 경우 하나 이상의 ECN 보고서를받지 못한 경우).
ECN 가능 RTMFP 수신기는 ECN-CE 로 표시된 패킷 수의 수를 최소한 유지합니다. 엔드 포인트는 ECN 보고서 청크에서 현재 카운터의 낮은 8 비트를 피어에게 보냅니다.
이 구현은 ECT(0) 를 보냅니다. 혼잡 컨트롤러는 마치 ECN-CE-count 의 증가에 응답합니다. ECT(0) 사용자 데이터가 포함 된 패킷으로 만 전송됩니다.
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;
congestionExperiencedCountMod256 : ECN-CE (ECN 혼잡 경험이있는)로 표시된 피어로부터받은 패킷 수의 낮은 8 비트. 
