Tidak, tidak ada whitepaper dan itu seperti 200 baris kode jadi tidak terlalu banyak untuk ditelan.
Di SignalR setiap pesan melewati sesuatu yang disebut bus pesan. Saat Anda ingin menskalakan di seluruh node (atau proses atau domain aplikasi), implementasi bus ini harus dapat berbicara dengan setiap instance aplikasi Anda. Untuk melakukan ini, Anda dapat menggunakan RedisMessageBus. Redis memiliki mekanisme sub pub serta kemampuannya untuk menyimpan pasangan nilai kunci dan kami hanya menggunakan yang pertama untuk SignalR.
OffTopic:Ini SANGAT penting! SignalR BUKAN perpesanan yang andal, ini adalah abstraksi koneksi. Kami mungkin menyangga pesan untuk longpolling tetapi Anda **tidak bisa* mengandalkan pesan yang ada di sana selamanya. Jika Anda memiliki pesan penting yang perlu Anda pertahankan, maka pertahankan.
Setiap server web terhubung ke satu (atau lebih dalam implementasi baru) redis acara untuk mengirim pesan di antara mereka. Ketika sebuah pesan masuk untuk satu atau lebih klien, itu dikirim ke backplane (redis) dan tiba di semua server web. Setiap server web mendapatkan pesan dari redis dan menyimpannya di cache lokal. Cache lokal ini adalah tempat klien SignalR (browser dll), dilayani.
Salah satu bagian penting dari desain scale out adalah kursor. Kursor mewakili di mana klien tertentu berada dalam aliran pesan yang tak terbatas. Ketika klien menyambung kembali setelah menjatuhkan koneksi atau koneksi longpolling datang kembali setelah mendapatkan pesan itu meminta bus untuk mendapatkan saya semuanya karena beberapa nilai kursor. Kursor ditentukan oleh implementasi bus pesan dan kami telah menormalkannya di sumber terbaru (belum dirilis pada saat penulisan tetapi saya tidak akan membahas detailnya di sini). Kursor dalam implementasi redis saat ini hanyalah angka yang bertambah, tidak terlalu rumit.
Semoga itu memberi gambaran tentang cara kerjanya.
