Temu duga umum: Bagaimanakah anda menguruskan keutamaan termultipleks dengan send group WebTransport?

Gesaan dan konteks

Satu sesi WebTransport tunggal mesti menghantar pratonton langsung, mesej kawalan, dan fail besar. Pratonton memerlukan kependaman rendah, mesej kawalan mesti tiba dengan segera, dan fail boleh mengalah dari segi lebar jalur. Gunakan WebTransportSendGroup, sendOrder, dan getStats() untuk mereka bentuk dasar penghantaran, termasuk sempadan keutamaan, kesesakan, penyambungan semula, pelayar yang tidak disokong, dan ralat.

MDN menerangkan send group sebagai satu set strim dan datagram yang keutamaan penghantaran relatifnya ditentukan oleh sendOrder; peruntukan lebar jalur merentasi kumpulan yang berbeza adalah ditakrifkan oleh pelaksanaan (implementation-defined). Antara muka ini kekal bersifat eksperimen. Artikel ini menyintesis bahan awam dan tidak mendakwa sebagai soalan temu duga khusus syarikat.

Perkara yang diuji oleh penemu duga

Penemu duga ingin melihat sama ada anda membezakan susunan relatif di dalam kumpulan daripada keadilan merentasi kumpulan, memetakan keutamaan perniagaan kepada baris gilir yang boleh diperhatikan, dan menerangkan perbezaan antara datagram yang tidak boleh dipercayai (unreliable) dan strim tertib yang boleh dipercayai (reliable). Jawapan yang kukuh menyebut tentang createSendGroup(), menghantar sendGroup semasa mencipta strim, sendOrder, getStats() peringkat kumpulan, kawalan kesesakan, dan pengesanan keupayaan; jawapan yang lemah hanya sekadar menyatakan untuk "memberi pemberat kepada mesej penting."

Soalan untuk dijelaskan terlebih dahulu

• Data manakah yang boleh digugurkan, dan data manakah yang mesti boleh dipercayai, tertib, dan tahan lama (durable)?
• Apakah sasaran kependaman, sasaran daya pemprosesan (throughput) fail, dan usia maksimum baris gilir?
• Adakah keutamaan ditetapkan secara kekal untuk sesi tersebut atau diubah oleh tindakan pengguna?
• Adakah pelayar sasaran menyokong send group, dan adakah sandaran boleh menyatakan semantik perniagaan yang sama?

Jawapan 30 saat

"Saya akan mengasingkan mesej kawalan yang boleh dipercayai, pratonton masa nyata yang bertolak ansur terhadap kehilangan (lossy), dan pemindahan fail latar belakang kepada ahli yang jelas. Ahli yang memerlukan susunan relatif berkongsi send group yang sama, dengan sendOrder meletakkan kawalan dan pratonton mendahului fail; ini bukan jaminan lebar jalur merentasi kumpulan. Penghantar mengehadkan baris gilir dan saiz item, memerhati baris gilir dan penyiapan melalui getStats(), menggugurkan pratonton lapuk, dan menjeda fail semasa kesesakan. Jika tidak disokong, ia berundur ke sambungan berasingan atau penjadual aplikasi sambil mengekalkan kebolehpercayaan mesej kawalan."

Penyelesaian langkah demi langkah

Mulakan dengan sempadan kebolehpercayaan. Gunakan strim yang boleh dipercayai untuk kawalan, kebenaran (authorization), dan pengesahan akhir; datagram boleh membawa pratonton langsung pakai buang; strim yang boleh dipercayai boleh membawa fail pada keutamaan rendah. Send group menyelesaikan susunan penghantaran relatif dalam kalangan ahli. Ia tidak mengubah kumpulan yang berbeza menjadi baris gilir berpemberat yang boleh diramal atau melakukan percubaan semula perniagaan.

Selepas mencipta kumpulan, kaitkan strim penghantaran atau strim datagram boleh tulis dengannya dan tetapkan sendOrder pada ahli. Dokumentasikan hubungan berangka dalam protokol supaya pelaksanaan tidak bercanggah mengenai sama ada nilai yang lebih besar atau lebih kecil yang menang. Hanya ahli yang mengambil bahagian dalam susunan ketat dalam kumpulan yang sama dibandingkan; susunan yang tidak ditetapkan adalah ditakrifkan oleh pelaksanaan.

const group = transport.createSendGroup();
const control = await transport.createUnidirectionalStream({
  sendGroup: group,
  sendOrder: 30,
});
const preview = transport.datagrams.createWritable({
  sendGroup: group,
  sendOrder: 20,
});
const archive = await transport.createUnidirectionalStream({
  sendGroup: group,
  sendOrder: 1,
});

Aplikasi masih memerlukan belanjawan: hadkan saiz dan usia datagram pratonton, dan gabungkan (coalesce) keadaan terkini untuk setiap objek; ketulan fail memerlukan pembatalan, percubaan semula, dan rekod titik semak (checkpoint). Apabila baris gilir menghampiri hadnya, gugurkan pratonton lapuk terlebih dahulu dan jeda fail, tetapi kekalkan mesej kawalan. Gunakan perakuan penerimaan (acknowledgements) dan kunci kedap perulangan (idempotency keys) untuk mesej kritikal; susunan hantar yang tinggi tidak membayangkan penghantaran terjamin.

Kawalan kesesakan ialah keutamaan pengangkutan, bukan SLA perniagaan yang ketat. congestionControl boleh menyatakan keutamaan kependaman rendah atau pemprosesan tinggi, tetapi hasilnya bergantung pada pelaksanaan dan keadaan rangkaian. Pilih keutamaan semasa membuat sambungan, kemudian gunakan metrik aplikasi untuk mengurangkan kekerapan pratonton atau menjeda kerja latar belakang; jangan mendakwa jaminan kependaman daripada satu pilihan sahaja.

Gunakan getStats() kumpulan dan metrik peringkat ahli untuk memerhatikan baris gilir, penghantaran, pengguguran, percubaan semula, dan kependaman penyiapan. Rekodkan dimensi untuk kumpulan, jenis mesej, rangkaian, dan versi sesi, membezakan antara "belum dihantar lagi", "datagram hilang", dan "penerima perlahan". Semasa menyambung semula, cipta kumpulan baharu, pulihkan keadaan strim yang boleh dipercayai, dan bina semula pratonton pakai buang daripada snapshot berwibawa dan bukannya menggunakan semula objek strim lapuk.

Kesan keupayaan sebelum membuka sesi. Jika send group tidak tersedia, strim kawalan teras mesti masih berfungsi; gunakan sambungan boleh dipercayai yang berasingan atau baris gilir aplikasi. Jangan sekat log masuk, kebenaran, atau penyerahan untuk mengekalkan pratonton visual. Sebelum melancarkan antara muka eksperimen, sediakan kohort pelayar, suis peluncuran (rollout switch), dan laluan pemutus kecemasan (kill path).

Contoh jawapan yang kukuh

Saya akan membahagikan mesej kawalan, pratonton langsung, dan pemindahan fail kepada ahli penghantaran yang berasingan, memilih strim atau datagram mengikut kebolehpercayaan. Ahli yang memerlukan susunan relatif berkongsi satu send group: kawalan mendapat sendOrder tertinggi, pratonton seterusnya, dan fail paling rendah; ahli tanpa susunan berada di luar perbandingan ketat. Susunan kumpulan adalah relatif, dan keadilan merentasi kumpulan adalah ditakrifkan oleh pelaksanaan, jadi saya tidak akan membentangkannya sebagai kuota lebar jalur.

Aplikasi menguruskan belanjawan, pembatalan, kedap perulangan, dan tamat tempoh: di bawah kesesakan, ia menggabungkan atau menggugurkan pratonton lama dan menjeda fail, manakala mesej kawalan mengekalkan perakuan yang boleh dipercayai. congestionControl menyatakan keutamaan, dan getStats() mengukur baris gilir dan kependaman penyiapan. Penyambungan semula membina semula kumpulan dan memulihkan daripada snapshot. Pelayar yang tidak disokong mengekalkan laluan kawalan yang boleh dipercayai dan merendahkan kualiti atau melumpuhkan pratonton. Saya akan memantau pengguguran, kependaman, dan kejayaan tugas mengikut kumpulan dan jenis mesej.

Kesilapan biasa

• Gejala → Menganggap sendOrder sebagai pemberat lebar jalur merentasi kumpulan; sebab ia gagal → API mentakrifkan susunan penghantaran relatif dalam kumpulan; pembetulan → Jadualkan merentasi kumpulan dalam aplikasi dan ukur hasilnya.
• Gejala → Menggantikan perakuan yang boleh dipercayai dengan keutamaan tinggi; sebab ia gagal → Susunan penghantaran tidak menjamin penghantaran; pembetulan → Gunakan strim yang boleh dipercayai, perakuan, dan kedap perulangan untuk mesej kritikal.
• Gejala → Terus membariskan setiap pratonton dan fail semasa kesesakan; sebab ia gagal → Kependaman dan ingatan menjadi tidak terhad; pembetulan → Tetapkan belanjawan, gabungkan keadaan terkini, dan jeda pemindahan latar belakang.
• Gejala → Menggunakan semula objek strim lama selepas sambung semula; sebab ia gagal → Objek tersebut milik sesi yang telah tamat tempoh; pembetulan → Bina semula kumpulan, pulihkan keadaan berwibawa, dan langgan semula.
• Gejala → Menjadikan API eksperimen sebagai satu-satunya saluran; sebab ia gagal → Perbezaan pelayar menyekat tindakan teras; pembetulan → Kesan keupayaan, laksanakan secara beransur-ansur, dan kekalkan sandaran yang boleh dipercayai.

Soalan susulan dan jawapan

Apakah perbezaan antara keutamaan kumpulan dan merentasi kumpulan?

Dalam satu send group, strim atau datagram yang mengambil bahagian dibandingkan dengan sendOrder; kumpulan yang berbeza dijangka menerima layanan yang adil, tetapi pecahan tepat adalah ditakrifkan oleh pelaksanaan. Untuk pemberat merentasi kumpulan, jadualkan baris gilir atau sambungan berasingan dalam aplikasi dan sahkan dengan metrik.

Mengapakah susunan hantar yang tinggi tidak mencukupi untuk melindungi pratonton?

Keutamaan mengubah susunan baris gilir; ia tidak mengubah sifat datagram yang tidak boleh dipercayai atau menjamin pemprosesan penerima. Pratonton masih memerlukan peraturan tamat tempoh, penggabungan, dan pengguguran. Fakta kawalan memerlukan pengangkutan yang boleh dipercayai, perakuan, dan ketahanan.

Bagaimanakah anda tahu bahawa menjeda fail telah membantu?

Jejak panjang baris gilir fail, kependaman pratonton, kependaman penyiapan kawalan, dan kejayaan tugas. Teruskan jika kependaman kawalan bertambah baik sementara pratonton memenuhi sasarannya; sambung semula fail dalam belanjawan apabila rangkaian atau keutamaan perniagaan berubah, mengelakkan kebuluran sumber (starvation) tanpa henti.

Apakah sandaran apabila send group tidak disokong?

Kekalkan strim kawalan yang boleh dipercayai dan navigasi teras terlebih dahulu. Halakan pratonton melalui laluan data yang berasingan, strim yang boleh dipercayai, atau tiada pratonton. Kekalkan protokol mesej dan peraturan pembatalan yang sama supaya kebenaran, penyerahan, dan semantik ralat kekal utuh.