rtmfp cpp
Version 1.5.1
Ini adalah implementasi C ++ (11) dari Secure Real-Time Flow Protocol (RTMFP) seperti yang dijelaskan dalam RFC 7016.
Perpustakaan mencakup adapter platform sampel dan utilitas lainnya, seperti loop run berbasis select() sederhana, tetapi ini tidak perlu digunakan. Implementasi Protokol dimaksudkan untuk dapat beradaptasi dengan lingkungan program host apa pun.
Perpustakaan ini ditujukan untuk klien, server, dan aplikasi P2P. Ini mencakup pembantu yang diperlukan dan kait panggilan balik untuk mendukung pengantar P2P dan penyeimbangan beban.
Direktori test mencakup tes unit dan contoh. Dari catatan khusus adalah tcserver , server media RTMFP dan RTMP langsung; tcrelay , relai/proxy rtmfp ↔︎ rtmp; dan redirector , penyeimbang beban sederhana.
Dokumentasi API yang paling lengkap saat ini ada di file header rtmfp.hpp .
Sebuah aplikasi akan membuat instantiate IPlatformAdapter dan ICryptoAdapter , lalu com::zenomt::rtmfp::RTMFP (yang membutuhkan adaptor ini). Biasanya adaptor platform perlu diberitahu tentang instance RTMFP baru sehingga dapat memohon metode platform instance (seperti howLongToSleep() dan onReceivePacket() ).
Platform akan menambahkan setidaknya satu antarmuka dengan memanggil RTMFP::addInterface() .
Aplikasi dapat membuka aliran pengiriman ke titik akhir baru atau saat ini dengan RTMFP::openFlow() dan Flow::openFlow , dan dapat membuka aliran pengembalian yang terkait dengan RecvFlow::openReturnFlow() .
Aplikasi dapat menerima aliran baru dengan mengatur panggilan balik onRecvFlow pada RTMFP (untuk aliran masuk yang telanjang) atau pada SendFlow S (untuk aliran pengembalian terkait).
Aplikasi dapat mengirim pesan ke rekan -rekan jauh dengan SendFlow::write() , dan menerima pesan dari rekan -rekan jauh dengan mengatur panggilan balik onMessage di RecvFlow s. Pesan dapat kedaluwarsa dan ditinggalkan jika tidak dimulai atau disampaikan dengan tenggat waktu per-pesan, atau dengan logika aplikasi sewenang-wenang menggunakan WriteReceipt yang dikembalikan oleh SendFlow::write() . Aplikasi dapat diberitahu dengan panggilan balik ketika pesan dikirim atau ditinggalkan.
SendFlow S diatur ke prioritas/prioritas PRI_PRIORITY , PRI_IMMEDIATE , PRI_FLASH , atau PRI_FLASHOVERRIDE dianggap waktu kritis. Mengirimkan Pesan Kritis Waktu Mempengaruhi Kontrol Kemacetan.
Setelah selesai, aplikasi dapat mematikan RTMFP dengan cara yang tertib atau tiba -tiba.
Implementasi protokol adalah satu utas dan tidak memiliki kunci/mutex. Semua panggilan ke API-nya harus disinkronkan secara eksternal, misalnya dengan semua berada di utas yang sama atau konstruk seperti run-loop. Ini dilakukan untuk meningkatkan portabilitas dan kinerja, karena penguncian bisa sangat mahal di CPU modern. Sinkronisasi diabstraksikan oleh metode perform adaptor platform untuk memungkinkan untuk membongkar beberapa operasi yang mahal atau memakan waktu untuk core/utas lain, jika diinginkan.
Implementasi protokol tidak secara langsung berinteraksi dengan soket UDP sistem operasi, jam, menjalankan loop, kunci, atau utas. Interaksi ini disarikan ke adaptor platform yang disediakan oleh program host.
Adaptor platform akan menjadi implementasi konkret dari com::zenomt::rtmfp::IPlatformAdapter , yang menyebut metode instance publik RTMFP di bagian “Digunakan oleh Platform Adapter”. Adaptor menyediakan waktu saat ini, membaca dan menulis ke soket, waktu, dan sinkronisasi.
Perpustakaan menyediakan dua contoh adaptor platform yang berjalan di RunLoop S: PosixPlatformAdapter untuk aplikasi utamanya murni, dan PerformerPosixPlatformAdapter untuk memungkinkan untuk membongkar kriptografi kunci publik intensif CPU ke utas pekerja. Adaptor platform ini harus cocok untuk banyak aplikasi pada sistem operasi seperti UNIX dan harus berfungsi sebagai contoh bagaimana menulis adaptor platform tunggal dan multi-threaded untuk aplikasi host Anda.
Tidak ada persyaratan untuk antarmuka Adaptor Platform menjadi soket UDP. Misalnya, antarmuka bisa berupa kaus kaki atau putar proxy, terowongan, atau simulator jaringan.
Untuk sistem operasi seperti UNIX, perpustakaan ini menyediakan loop run berbasis select() sederhana yang cocok untuk banyak aplikasi berbasis soket. Ini juga mencakup loop run berbasis epoll sederhana untuk Linux yang berskala lebih baik dari select() untuk menangani banyak soket. Gunakan alias PreferredRunLoop untuk secara otomatis memilih varian terbaik yang tersedia pada waktu kompilasi untuk OS target.
Seorang Performer dapat dilampirkan ke loop run untuk memungkinkan meminta tugas di dalam/disinkronkan dengan loop run dari utas apa pun. Performer S digunakan dengan PerformerPosixPlatformAdapter .
Microsoft Windows bukan platform yang didukung secara resmi . Namun, perpustakaan inti (tidak termasuk adaptor platform, menjalankan loop, dan Performer ) harus dibangun di atas jendela, dan pemeliharaan inti untuk platform itu akan dicoba sebagai waktu dan bantuan dari masyarakat memungkinkan. Harap buka masalah jika ada masalah dengan perpustakaan inti di Windows.
Untuk menggunakan pustaka ini di Windows, Anda harus menyediakan adaptor platform yang sesuai.
Silakan hubungi pengelola atau buka masalah untuk meminta tautan ke adaptor platform Windows Anda untuk ditambahkan di sini dalam dokumen ini.
RFC 7016 menjelaskan kerangka kerja umum untuk mengamankan komunikasi RTMFP sesuai dengan kebutuhan aplikasi, dan meninggalkan spesifik kriptografi ke profil kriptografi . Perpustakaan ini tidak mengunci aplikasinya ke profil kriptografi tertentu, dan ditulis untuk mendukung banyak profil potensial. Profil kriptografi diimplementasikan oleh ICryptoAdapter beton yang disediakan untuk RTMFP pada instantiasi.
Sebagian besar aplikasi RTMFP akan menggunakan profil kriptografi untuk komunikasi flash yang dijelaskan dalam RFC 7425. Ini disediakan oleh FlashCryptoAdapter . Perhatikan bahwa adaptor ini abstrak dan harus disubkilasi untuk memberikan implementasi konkret dari primitif kriptografi yang diperlukan. Implementasi konkret menggunakan OpenSSL disediakan oleh FlashCryptoAdapter_OpenSSL , yang juga dapat berfungsi sebagai contoh cara menggunakan perpustakaan kriptografi lainnya. Jika Anda tidak memiliki OpenSSL atau Anda tidak ingin menggunakannya, Anda dapat menekan membangun modul ini dengan mendefinisikan variabel make variabel WITHOUT_OPENSSL . Jika openssl Anda diinstal di luar default kompiler Anda termasuk dan jalur pencarian linker, Anda dapat mendefinisikan variabel make OPENSSL_INCLUDEDIR dan OPENSSL_LIBDIR dengan arahan yang sesuai (lihat Makefile untuk contoh).
Implementasi OpenSSL dari FlashCryptoAdapter mengimplementasikan 4096-bit Internet Key Exchange (IKE) Group 16, 2048-bit IKE Group 14, dan 1024-bit IKE Group 2 untuk perjanjian kunci diffie-Hellman. Semua implementasi profil kriptografi komunikasi flash harus mengimplementasikan setidaknya Grup 2; Beberapa juga mengimplementasikan Grup 14. Implementasi ini lebih memilih kelompok umum terkuat.
Perhatikan bahwa RTMFP tidak terbatas pada komunikasi platform flash. Perpustakaan ini menyediakan PlainCryptoAdapter yang cocok untuk pengujian dan evaluasi. Karena tidak memberikan kriptografi aktual (dan metode cryptoHash256() dan pseudoRandomBytes() sangat lemah), tidak cocok untuk penggunaan produksi di internet terbuka. Jangan.
Bufferbloat (buffering dan antrian yang berlebihan dalam jaringan) dapat menyebabkan penundaan ujung ke ujung tinggi yang menghasilkan kinerja yang tidak dapat diterima untuk aplikasi real-time. Sayangnya, solusi terbaik untuk masalah ini (manajemen antrian aktif dengan pemberitahuan kemacetan eksplisit) tidak digunakan secara universal di internet saat ini.
Selain sinyal kemacetan normal (kehilangan dan pemberitahuan kemacetan eksplisit), perpustakaan ini secara opsional dapat menyimpulkan kemungkinan kemacetan pada sesi dari peningkatan waktu perjalanan pulang pergi (RTT). Untuk mengaktifkan kemampuan ini, gunakan Flow::setSessionCongestionDelay() untuk menetapkan jumlah penundaan tambahan di atas RTT awal yang akan ditafsirkan sebagai indikasi kemacetan. Nilai defaultnya INFINITY . Nilai 0.1 detik penundaan tambahan disarankan untuk fitur ini.
RTT awal adalah RTT minimum yang diamati hampir tiga menit terakhir. Jendela observasi RTT awal dibersihkan dan diatur ulang dalam keadaan berikut:
Dari waktu ke waktu, jika sebagian besar jendela kemacetan digunakan, jendela kemacetan akan dikurangi sementara untuk menyelidiki jalur untuk RTT baseline baru (jika pengiriman kami sendiri menutupi baseline). Perhatikan bahwa ini dapat menyebabkan jitter.
Jika RTT yang dihaluskan diamati berada di atas baseline ditambah CongestionDelay yang dikonfigurasi (dan juga setidaknya 30 ms), ini diasumsikan sebagai indikasi kemacetan. Pengontrol kemacetan menanggapi ini seolah -olah itu kerugian.
Skema deteksi kemacetan ini, seperti semua yang berbasis penundaan ujung ke ujung, tidak sempurna, dan tunduk pada sinyal positif palsu yang disebabkan oleh kasus-kasus termasuk:
Dengan demikian, fitur ini mungkin tidak diindikasikan untuk semua kasus penggunaan. Perawatan harus diambil untuk mengaktifkan fitur ini hanya ketika sinyal kemacetan positif palsu tidak mungkin, seperti untuk transmisi media yang secara substansial searah melalui kemacetan khusus. Positif palsu dapat menyebabkan kelaparan transmisi.
Fitur ini diilhami oleh transport latar belakang penundaan ekstra rendah (LEDBAT), adaptasi laju yang terkunci sendiri untuk multimedia (Scream), dan algoritma kontrol kemacetan BBR Google.
Implementasi RTMFP ini menambah dukungan untuk Explicit Macettion Notification (ECN). Ini menambahkan potongan eksperimental baru "Laporan ECN" (Tipe 0xec ) untuk penerima untuk mengirim jumlah ECN codepoints yang diterima kembali ke pengirim ECN. RTMFP tidak boleh mengirim laporan ECN ke rekannya kecuali jika telah menerima setidaknya satu paket yang valid dalam sesi S_OPEN -nya dengan rekan yang ditandai dengan titik kode transportasi ECN yang mampu ( ECT(0) , ECT(1) , atau ECN-CE ).
Penerima RTMFP yang berkemampuan ECN mengirimkan laporan ECN ke rekannya yang berkemampuan ECN. Laporan ECN harus dikumpulkan sebelum potongan pengakuan pertama dalam paket apa pun yang berisi pengakuan (untuk menghindari pemotongan laporan). Agar pengirim ECN dapat mendeteksi apakah antarmuka yang dekat dan jauh, jalur, dan dukungan penerima ECN, penerima berkemampuan ECN harus mengirim laporan ECN dalam paket apa pun yang berisi pengakuan, jika ada paket yang ditandai dengan titik transportasi ECN yang telah diterima baik sejak terakhir kali laporan ECN dikirim atau jika laporan belum dikirim.
Pengirim RTMFP harus berhenti menandai paket dengan ECN yang mampu kode transportasi yang mampu jika ia menentukan bahwa penerima tidak dapat dikeluarkan ECN (misalnya, jika pengirim belum menerima setidaknya satu laporan ECN bersama dengan pengakuan untuk data pengguna yang dikirim dalam paket yang ditandai selama sesi terbuka dengan rekan).
Penerima RTMFP berkemampuan ECN menyimpan setidaknya jumlah jumlah paket yang diterima ditandai dengan ECN-CE . Titik akhir mengirimkan 8 bit rendah dari konter saat ini ke rekannya di ECN Report Chunks.
Implementasi ini mengirimkan ECT(0) . Pengontrol kemacetan menanggapi peningkatan ECN-CE-count seolah-olah itu kerugian. ECT(0) hanya dikirim pada paket yang berisi data pengguna.
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 : rendah 8 bit dari jumlah paket yang diterima dari rekan yang ditandai dengan ECN-CE (ECN consanction berpengalaman). 
