Pengantar SignalR

oleh Patrick Fletcher

Peringatan

Dokumentasi ini bukan untuk versi terbaru SignalR. Lihat ASP.NET Core SignalR.

Artikel ini menjelaskan apa itu SignalR, dan beberapa solusi yang dirancang untuk dibuat.

Pertanyaan dan komentar

Silakan tinggalkan umpan balik tentang bagaimana Anda menyukai tutorial ini dan apa yang dapat kami tingkatkan di komentar di bagian bawah halaman. Jika Anda memiliki pertanyaan yang tidak terkait langsung dengan tutorial, Anda dapat mempostingnya ke forum ASP.NET SignalR atau StackOverflow.com.

Apa itu SignalR?

ASP.NET SignalR adalah pustaka untuk pengembang ASP.NET yang menyederhanakan proses penambahan fungsionalitas web real-time ke aplikasi. Fungsionalitas web real-time adalah kemampuan untuk memiliki kode server mendorong konten ke klien yang terhubung secara instan saat tersedia, daripada meminta server menunggu klien untuk meminta data baru.

SignalR dapat digunakan untuk menambahkan segala jenis fungsionalitas web "real-time" ke aplikasi ASP.NET Anda. Meskipun obrolan sering digunakan sebagai contoh, Anda dapat melakukan lebih banyak hal. Setiap kali pengguna me-refresh halaman web untuk melihat data baru, atau halaman menerapkan polling panjang untuk mengambil data baru, itu adalah kandidat untuk menggunakan SignalR. Contohnya termasuk dasbor dan aplikasi pemantauan, aplikasi kolaboratif (seperti pengeditan dokumen secara bersamaan), pembaruan kemajuan pekerjaan, dan formulir real-time.

SignalR juga memungkinkan jenis aplikasi web yang benar-benar baru yang memerlukan pembaruan frekuensi tinggi dari server, misalnya, game real time.

SignalR menyediakan API sederhana untuk membuat panggilan prosedur jarak jauh (RPC) server-ke-klien yang memanggil fungsi JavaScript di browser klien (dan platform klien lainnya) dari kode .NET sisi server. SignalR juga menyertakan API untuk manajemen koneksi (misalnya, peristiwa sambungkan dan putuskan sambungan), dan koneksi pengelompokan.

SignalR menangani manajemen koneksi secara otomatis, dan memungkinkan Anda menyiarkan pesan ke semua klien yang terhubung secara bersamaan, seperti ruang obrolan. Anda juga dapat mengirim pesan ke klien tertentu. Koneksi antara klien dan server menjadi lancar, tidak seperti koneksi HTTP klasik, yang dibuat ulang untuk setiap komunikasi.

SignalR mendukung fungsionalitas "dorongan server", di mana kode server dapat memanggil kode klien di browser menggunakan Panggilan Prosedur Jarak Jauh (RPC), daripada model respons permintaan yang umum di web saat ini.

Aplikasi SignalR dapat menskalakan ke ribuan klien menggunakan penyedia peluasan skala bawaan dan pihak ketiga.

Penyedia bawaan meliputi:

• Service Bus
• SQL Server
• Redis

Penyedia pihak ketiga meliputi:

• NCache.

SignalR adalah sumber terbuka, dapat diakses melalui GitHub.

SignalR dan WebSocket

SignalR menggunakan transportasi WebSocket baru jika tersedia dan kembali ke transportasi yang lebih lama jika perlu. Meskipun Anda pasti dapat menulis aplikasi Anda menggunakan WebSocket secara langsung, menggunakan SignalR berarti bahwa banyak fungsi tambahan yang perlu Anda terapkan sudah dilakukan untuk Anda. Yang terpenting, ini berarti Anda dapat membuat kode aplikasi untuk memanfaatkan WebSocket tanpa harus khawatir tentang membuat jalur kode terpisah untuk klien yang lebih lama. SignalR juga melindungi Anda dari kekhawatirkan pembaruan WebSocket, karena SignalR diperbarui untuk mendukung perubahan dalam transportasi yang mendasar, memberikan aplikasi Anda antarmuka yang konsisten di seluruh versi WebSocket.

Transportasi dan fallback

SignalR adalah abstraksi atas beberapa transportasi yang diperlukan untuk melakukan pekerjaan real time antara klien dan server. SignalR pertama kali mencoba membuat koneksi WebSocket jika memungkinkan. WebSocket adalah transportasi optimal untuk SignalR karena memiliki:

• Penggunaan memori server yang paling efisien.
• Latensi terendah.
• Fitur yang paling mendasar, seperti komunikasi dupleks penuh antara klien dan server.
• Persyaratan yang paling ketat, WebSocket memerlukan server:
  • Jalankan pada Windows Server 2012 atau Windows 8.
  • .NET Framework 4.5.

Jika persyaratan ini tidak terpenuhi, SignalR mencoba menggunakan transportasi lain untuk membuat koneksinya.

Transportasi HTML 5

Transportasi ini bergantung pada dukungan untuk HTML 5. Jika browser klien tidak mendukung standar HTML 5, transportasi yang lebih lama akan digunakan.

• WebSocket (jika server dan browser menunjukkan bahwa mereka dapat mendukung Websocket). WebSocket adalah satu-satunya transportasi yang membangun koneksi dua arah persisten sejati antara klien dan server. Namun, WebSocket juga memiliki persyaratan yang paling ketat; ini sepenuhnya didukung hanya dalam versi terbaru Microsoft Internet Explorer, Google Chrome, dan Mozilla Firefox, dan hanya memiliki implementasi parsial di browser lain seperti Opera dan Safari.
• Peristiwa Terkirim Server, juga dikenal sebagai EventSource (jika browser mendukung Peristiwa Terkirim Server, yang pada dasarnya adalah semua browser kecuali Internet Explorer.)

Transportasi komtes

Transportasi berikut didasarkan pada model aplikasi web Comet , di mana browser atau klien lain mempertahankan permintaan HTTP yang lama disimpan, yang dapat digunakan server untuk mendorong data ke klien tanpa klien secara khusus memintanya.

• Forever Frame (hanya untuk Internet Explorer). Forever Frame membuat IFrame tersembunyi yang membuat permintaan ke titik akhir di server yang tidak selesai. Server kemudian terus mengirim skrip ke klien yang segera dijalankan, menyediakan koneksi realtime satu arah dari server ke klien. Koneksi dari klien ke server menggunakan koneksi terpisah dari server ke koneksi klien, dan seperti permintaan HTTP standar, koneksi baru dibuat untuk setiap bagian data yang perlu dikirim.
• Polling panjang Ajax. Polling panjang tidak membuat koneksi persisten, tetapi sebaliknya melakukan polling server dengan permintaan yang tetap terbuka sampai server merespons, di mana koneksi ditutup, dan koneksi baru diminta segera. Ini dapat memperkenalkan beberapa latensi saat koneksi direset.

Untuk informasi selengkapnya tentang transportasi apa yang didukung di konfigurasi mana, lihat Platform yang Didukung.

Proses pemilihan transportasi

Daftar berikut menunjukkan langkah-langkah yang digunakan SignalR untuk memutuskan transportasi mana yang akan digunakan.

1. Jika browser adalah Internet Explorer 8 atau yang lebih lama, Long Polling digunakan.

2. Jika JSONP dikonfigurasi (yaitu, jsonp parameter diatur ke true saat koneksi dimulai), Polling Panjang digunakan.

3. Jika koneksi lintas domain sedang dibuat (yaitu, jika titik akhir SignalR tidak berada di domain yang sama dengan halaman hosting), maka WebSocket akan digunakan jika kriteria berikut terpenuhi:

   • Klien mendukung CORS (Berbagi Sumber Daya Lintas Asal). Untuk detail tentang klien mana yang mendukung CORS, lihat CORS di caniuse.com.

   • Klien mendukung WebSocket

   • Server mendukung WebSocket

     Jika salah satu kriteria ini tidak terpenuhi, Long Polling akan digunakan. Untuk informasi selengkapnya tentang koneksi lintas domain, lihat Cara membuat koneksi lintas domain.

4. Jika JSONP tidak dikonfigurasi dan koneksi bukan lintas domain, WebSocket akan digunakan jika klien dan server mendukungnya.

5. Jika klien atau server tidak mendukung WebSocket, Server Sent Events digunakan jika tersedia.

6. Jika Peristiwa Terkirim Server tidak tersedia, Forever Frame akan dicoba.

7. Jika Selamanya Bingkai gagal, Polling Panjang digunakan.

Memantau transportasi

Anda dapat menentukan transportasi apa yang digunakan aplikasi Anda dengan mengaktifkan pengelogan di hub Anda, dan membuka jendela konsol di browser Anda.

Untuk mengaktifkan pengelogan untuk peristiwa hub Anda di browser, tambahkan perintah berikut ke aplikasi klien Anda:

$.connection.hub.logging = true;

• Di Internet Explorer, buka alat pengembang dengan menekan F12, dan klik tab Konsol.

  

• Di Chrome, buka konsol dengan menekan Ctrl+Shift+J.

  

Dengan konsol terbuka dan pengelogan diaktifkan, Anda akan dapat melihat transportasi mana yang digunakan oleh SignalR.

Menentukan transportasi

Negosiasi transportasi membutuhkan waktu tertentu dan sumber daya klien/server. Jika kemampuan klien diketahui, maka transportasi dapat ditentukan ketika koneksi klien dimulai. Cuplikan kode berikut menunjukkan memulai koneksi menggunakan transportasi Ajax Long Polling, seperti yang akan digunakan jika diketahui bahwa klien tidak mendukung protokol lain:

connection.start({ transport: 'longPolling' });

Anda dapat menentukan urutan fallback jika Anda ingin klien mencoba transportasi tertentu secara berurutan. Cuplikan kode berikut menunjukkan mencoba WebSocket, dan gagal itu, langsung masuk ke Polling Panjang.

connection.start({ transport: ['webSockets','longPolling'] });

Konstanta string untuk menentukan transportasi didefinisikan sebagai berikut:

• webSockets
• foreverFrame
• serverSentEvents
• longPolling

Koneksi dan Hub

SignalR API berisi dua model untuk berkomunikasi antara klien dan server: Koneksi Persisten dan Hub.

Koneksi mewakili titik akhir sederhana untuk mengirim pesan penerima tunggal, dikelompokkan, atau disiarkan. API Koneksi Persisten (diwakili dalam kode .NET oleh kelas PersistentConnection) memberi pengembang akses langsung ke protokol komunikasi tingkat rendah yang diekspos SignalR. Menggunakan model komunikasi Koneksi akan akrab bagi pengembang yang telah menggunakan API berbasis koneksi seperti Windows Communication Foundation.

Hub adalah alur tingkat tinggi yang dibangun di atas API Koneksi yang memungkinkan klien dan server Anda untuk memanggil metode satu sama lain secara langsung. SignalR menangani pengiriman di seluruh batas komputer seolah-olah dengan sihir, memungkinkan klien untuk memanggil metode di server semampu metode lokal, dan sebaliknya. Menggunakan model komunikasi Hub akan akrab bagi pengembang yang telah menggunakan API pemanggilan jarak jauh seperti .NET Remoting. Menggunakan Hub juga memungkinkan Anda untuk meneruskan parameter yang ditik dengan kuat ke metode, memungkinkan pengikatan model.

Diagram arsitektur

Diagram berikut menunjukkan hubungan antara Hub, Koneksi Persisten, dan teknologi mendasar yang digunakan untuk transportasi.

Cara kerja Hub

Ketika kode sisi server memanggil metode pada klien, paket dikirim di seluruh transportasi aktif yang berisi nama dan parameter metode yang akan dipanggil (ketika objek dikirim sebagai parameter metode, itu diserialisasikan menggunakan JSON). Klien kemudian mencocokkan nama metode dengan metode yang ditentukan dalam kode sisi klien. Jika ada kecocokan, metode klien akan dijalankan menggunakan data parameter yang dideserialisasi.

Panggilan metode dapat dipantau menggunakan alat seperti Fiddler. Gambar berikut menunjukkan panggilan metode yang dikirim dari server SignalR ke klien browser web di panel Log Fiddler. Panggilan metode sedang dikirim dari hub yang disebut MoveShapeHub, dan metode yang dipanggil disebut updateShape.

Dalam contoh ini, nama hub diidentifikasi dengan H parameter ; nama metode diidentifikasi dengan M parameter , dan data yang dikirim ke metode diidentifikasi dengan A parameter . Aplikasi yang menghasilkan pesan ini dibuat dalam tutorial Realtime Frekuensi Tinggi .

Memilih model komunikasi

Sebagian besar aplikasi harus menggunakan API Hubs. CONNECTIONS API dapat digunakan dalam keadaan berikut:

• Format pesan aktual yang dikirim perlu ditentukan.
• Pengembang lebih suka bekerja dengan model olahpesan dan pengiriman daripada model pemanggilan jarak jauh.
• Aplikasi yang sudah ada yang menggunakan model olahpesan sedang di-port untuk menggunakan SignalR.