Bagikan melalui

Saluran Data

  • Artikel

Catatan

Dokumen ini mempelajari fitur Saluran Data yang ada di Azure Communication Services Calling SDK. Meskipun Saluran Data dalam konteks ini memiliki beberapa kesamaan dengan Saluran Data di WebRTC, sangat penting untuk mengenali perbedaan halus dalam spesifikasinya. Di seluruh dokumen ini, kami menggunakan istilah Data Channel API atau API untuk menunjukkan API Saluran Data dalam SDK. Jika mengacu pada DATA Channel API di WebRTC, kami secara eksplisit menggunakan istilah WebRTC Data Channel API untuk kejelasan dan presisi.

API Saluran Data memungkinkan olahpesan real-time selama panggilan audio dan video. Dengan API ini, Anda sekarang dapat dengan mudah mengintegrasikan fungsionalitas pertukaran data ke dalam aplikasi, memberikan pengalaman komunikasi yang mulus bagi pengguna. Fitur-fitur kunci mencakup:

  • Olahpesan Real Time: API Saluran Data memungkinkan pengguna untuk langsung mengirim dan menerima pesan selama panggilan audio atau video yang sedang berlangsung, mempromosikan komunikasi yang lancar dan efisien. Dalam skenario panggilan grup, pesan dapat dikirim ke satu peserta, sekumpulan peserta tertentu, atau semua peserta dalam panggilan. Fleksibilitas ini meningkatkan komunikasi dan kolaborasi di antara pengguna selama interaksi grup.
  • Komunikasi Unidirectional: Tidak seperti komunikasi dua arah, DATA Channel API dirancang untuk komunikasi searah. Ini menggunakan objek yang berbeda untuk mengirim dan menerima pesan: objek DataChannelSender untuk dikirim dan objek DataChannelReceiver untuk menerima. Pemisahan ini menyederhanakan manajemen pesan dalam panggilan grup, yang mengarah ke pengalaman pengguna yang lebih efisien.
  • Dukungan Data Biner: API mendukung pengiriman dan penerimaan data biner, memungkinkan pertukaran jenis data yang beragam, seperti teks, gambar, dan file. Pesan teks harus diserialisasikan ke dalam buffer byte sebelum dapat ditransmisikan.
  • Opsi Pengirim: API Saluran Data menyediakan tiga opsi yang dapat dikonfigurasi saat membuat objek pengirim, termasuk Keandalan, Prioritas, dan Laju Bit. Opsi ini memungkinkan konfigurasi saluran untuk memenuhi kebutuhan khusus untuk kasus penggunaan yang berbeda.
  • Keamanan: Semua pesan yang dipertukarkan antara klien dan titik akhir lainnya dienkripsi, memastikan privasi dan keamanan data pengguna.

Kasus penggunaan umum

Saluran Data dapat digunakan dalam berbagai skenario. Dua contoh kasus penggunaan umum adalah:

Olahpesan antar peserta dalam panggilan

API Saluran Data memungkinkan transmisi pesan jenis biner di antara peserta panggilan. Dengan serialisasi yang sesuai dalam aplikasi, ia dapat mengirimkan berbagai jenis pesan untuk tujuan yang berbeda. Ada juga pustaka atau layanan lain yang menyediakan fungsionalitas olahpesan. Masing-masing memiliki kelebihan dan kekurangannya. Anda harus memilih yang cocok untuk skenario penggunaan Anda. Misalnya, DATA Channel API menawarkan keuntungan dari komunikasi latensi rendah, dan menyederhanakan manajemen pengguna karena tidak perlu mempertahankan daftar peserta terpisah. Namun, fitur saluran data tidak memberikan persistensi pesan dan tidak menjamin bahwa pesan tidak akan hilang secara end-to-end. Jika Anda memerlukan pesan stateful atau pengiriman yang dijamin, Anda mungkin ingin mempertimbangkan solusi alternatif.

Berbagi file

Berbagi file mewakili kasus penggunaan umum lainnya untuk DATA Channel API. Dalam skenario panggilan peer-to-peer, koneksi Saluran Data berfungsi berdasarkan peer-to-peer. Penyiapan ini menawarkan metode yang efisien untuk transfer file, memanfaatkan sepenuhnya koneksi langsung dan peer-to-peer untuk meningkatkan kecepatan dan mengurangi latensi.

Dalam skenario panggilan grup, file masih dapat dibagikan di antara peserta. Namun, ada cara yang lebih baik, seperti Azure Storage atau Azure Files. Selain itu, menyiarkan konten file kepada semua peserta dalam panggilan dapat dicapai dengan mengatur daftar peserta kosong. Namun, penting untuk diingat bahwa, selain keterbatasan bandwidth, ada batasan lebih lanjut yang diberlakukan selama panggilan grup saat menyiarkan pesan, seperti laju paket dan tekanan balik dari laju bit penerimaan.

Konsep kunci

Komunikasi unidirectional

API Saluran Data dirancang untuk komunikasi searah, dibandingkan dengan komunikasi dua arah di Saluran Data WebRTC. Ini menggunakan objek terpisah untuk mengirim dan menerima pesan, dengan objek DataChannelSender yang bertanggung jawab untuk mengirim pesan dan objek DataChannelReceiver untuk menerima pesan.

Pemisahan objek pengirim dan penerima menyederhanakan penanganan pesan dalam skenario panggilan grup, memberikan pengalaman yang lebih efisien dan ramah pengguna.

Saluran

Setiap pesan Saluran Data dikaitkan dengan saluran tertentu yang diidentifikasi oleh channelId. Penting untuk mengklarifikasi bahwa channelId ini tidak terkait dengan id properti di Saluran Data WebRTC. ChannelId ini dapat digunakan untuk membedakan berbagai penggunaan aplikasi, seperti menggunakan 1000 untuk pesan kontrol dan 1001 untuk transfer gambar.

channelId ditetapkan selama pembuatan objek DataChannelSender, dan dapat ditentukan pengguna atau ditentukan oleh SDK jika dibiarkan tidak ditentukan.

Rentang channelId yang valid terletak antara 1 dan 65535. Jika channelId 0 disediakan, atau jika tidak ada channelId yang disediakan, SDK menetapkan channelId yang tersedia dari dalam rentang yang valid.

Keandalan

Setelah dibuat, saluran dapat dikonfigurasi untuk menjadi salah satu dari dua opsi Keandalan: lossy atau durable.

Saluran lossy berarti urutan pesan tidak dijamin dan pesan dapat diam-diam dihilangkan saat pengiriman gagal. Ini umumnya mampu kecepatan transfer data yang lebih cepat.

Saluran durable berarti SDK menjamin pengiriman pesan yang tidak hilang dan dipesan. Dalam kasus ketika pesan tidak dapat dikirimkan, SDK akan melemparkan pengecualian. Di Web SDK, durabilitas saluran dipastikan melalui koneksi SCTP yang andal. Namun, tidak menyiratkan bahwa pesan tidak akan hilang secara end-to-end. Dalam konteks panggilan grup, ini menandakan pencegahan kehilangan pesan antara pengirim dan server. Dalam panggilan peer-to-peer, ini menunjukkan transmisi yang andal antara pengirim dan titik akhir jarak jauh.

Catatan

Dalam implementasi Web SDK saat ini, transmisi data dilakukan melalui koneksi Saluran Data WebRTC yang andal untuk saluran dan durable .lossy

Prioritas

Setelah dibuat, saluran dapat dikonfigurasi untuk menjadi salah satu dari dua opsi Prioritas: normal atau high.

Untuk Web SDK, pengaturan prioritas hanya dibandingkan di antara saluran di sisi pengirim. Saluran dengan high prioritas diberikan prioritas yang lebih tinggi untuk transmisi dibandingkan dengan yang memiliki normal prioritas.

Laju bit

Saat membuat saluran, laju bit yang diinginkan dapat ditentukan untuk alokasi bandwidth.

Properti Laju Bit ini adalah untuk memberi tahu SDK tentang persyaratan bandwidth yang diharapkan untuk kasus penggunaan tertentu. Meskipun SDK umumnya tidak dapat mencocokkan laju bit yang tepat, SDK mencoba mengakomodasi permintaan.

Sesi

API Saluran Data memperkenalkan konsep sesi, yang mematuhi semantik terbuka. Di SDK, sesi dikaitkan dengan pengirim atau objek penerima.

Setelah membuat objek pengirim dengan channelId baru, objek pengirim dalam status terbuka. close() Jika API dipanggil pada objek pengirim, sesi menjadi tertutup dan tidak dapat lagi memfasilitasi pengiriman pesan. Pada saat yang sama, objek pengirim memberi tahu semua peserta dalam panggilan bahwa sesi ditutup.

Jika objek pengirim dibuat dengan channelId yang sudah ada, objek pengirim yang ada yang terkait dengan channelId akan ditutup dan pesan apa pun yang dikirim dari objek pengirim yang baru dibuat akan dikenali sebagai bagian dari sesi baru.

Dari perspektif penerima, pesan yang berasal dari sesi yang berbeda di sisi pengirim diarahkan ke objek penerima yang berbeda. Jika SDK mengidentifikasi sesi baru yang terkait dengan channelId yang ada di sisi penerima, SDK akan membuat objek penerima baru. SDK tidak menutup objek penerima yang lebih lama; penutupan tersebut terjadi 1) ketika objek penerima menerima pemberitahuan penutupan dari pengirim, atau 2) jika sesi belum menerima pesan apa pun dari pengirim selama lebih dari dua menit.

Dalam kasus di mana sesi objek penerima ditutup dan tidak ada sesi baru untuk channelId yang sama ada di sisi penerima, SDK membuat objek penerima baru setelah menerima pesan dari sesi yang sama di lain waktu. Namun, jika sesi baru untuk channelId yang sama ada di sisi penerima, SDK akan membuang pesan masuk dari sesi sebelumnya.

Mengingat bahwa objek penerima ditutup jika tidak menerima pesan selama lebih dari dua menit, kami menyarankan agar aplikasi secara berkala mengirim pesan tetap hidup dari sisi pengirim untuk mempertahankan status aktif objek penerima.

Nomor urut

Nomor urut adalah bilangan bulat yang tidak ditandatangani 32-bit yang disertakan dalam pesan Saluran Data untuk menunjukkan urutan pesan dalam saluran. Penting untuk dicatat bahwa nomor ini dihasilkan dari perspektif pengirim. Akibatnya, penerima mungkin melihat celah dalam nomor urut jika pengirim mengubah penerima selama mengirim pesan.

Misalnya, pertimbangkan skenario di mana pengirim mengirim tiga pesan. Awalnya, penerima adalah Peserta A dan Peserta B. Setelah pesan pertama, pengirim mengubah penerima menjadi Peserta B, dan sebelum pesan ketiga, penerima dialihkan ke peserta A. Dalam hal ini, Peserta A akan menerima dua pesan dengan nomor urut 1 dan 3. Namun, ini tidak menandakan kehilangan pesan tetapi hanya mencerminkan perubahan penerima oleh pengirim.

Batasan

Ukuran pesan

Ukuran maksimum yang diperbolehkan untuk satu pesan adalah 32 KB. Jika Anda perlu mengirim data yang lebih besar dari batas, Anda harus membagi data menjadi beberapa pesan.

Daftar peserta

Jumlah maksimum peserta dalam daftar dibatasi hingga 64. Jika Anda ingin menentukan lebih banyak peserta, Anda harus mengelola daftar peserta sendiri. Misalnya, jika Anda ingin mengirim pesan ke 50 peserta, Anda dapat membuat dua saluran berbeda, masing-masing dengan 25 peserta dalam daftar penerima mereka. Saat menghitung batas, dua titik akhir dengan pengidentifikasi peserta yang sama akan dihitung sebagai entitas terpisah. Sebagai alternatif, Anda dapat memilih untuk menyiarkan pesan. Namun, pembatasan tertentu berlaku saat menyiarkan pesan.

Pembatasan tarif

Saat ini SDK panggilan memiliki pembatasan tarif yang diterapkan, yang mencegah pengguna mengirim data dengan kecepatan yang lebih tinggi meskipun jaringan mereka mengizinkannya. Tingkat bandwidth saat ini maksimum untuk saluran data adalah:

  • Saluran andal (Tahan Lama): 64 kbps
  • Saluran tidak dapat diandalkan (Lossy): 512 kbps
  • Saluran prioritas tinggi tidak dapat diandalkan: 200 kbps

Namun, saat menyiarkan pesan, batas laju bit kirim bersifat dinamis dan tergantung pada laju bit penerima. Dalam implementasi saat ini, batas laju bit kirim dihitung sebagai laju bit kirim maksimum minus 80% dari laju bit penerima.

Selain itu, kami juga memberlakukan pembatasan tarif paket saat mengirim pesan siaran. Batas saat ini ditetapkan pada 80 paket per detik, di mana setiap 1200 byte dalam pesan dihitung sebagai satu paket. Langkah-langkah ini diberlakukan untuk mencegah banjir ketika sejumlah besar peserta dalam panggilan grup menyiarkan pesan.

Langkah berikutnya

Untuk informasi lebih lanjut, baca artikel berikut: