SSE(1)は ASP.NET コアをSSEサーバーとして使用しています

クズども · 2024年4月5日 11:54:12に投稿

SSE導入

SSEはServer-Sent Eventsの略で、文字通りサーバーがクライアントに情報をプッシュすることを意味します。 SSEは一方通行チャネルです。サーバーはクライアントにしか情報を送れませんクライアントは初回トリガー後にしかSSEリクエストを受け取れず、応答できません。

SSEの主な特徴は以下の通りです:

使いやすさ:SSEはプレーンテキストやJSONなどのテキストベースのデータ形式を使用しているため、データの送信や解析が比較的簡単です。
一方通行通信:SSEはサーバーとクライアント間の一方通行通信をサポートしており、サーバーはクライアントに積極的にデータをプッシュでき、クライアントはデータのみを受け取ることができます。
リアルタイム:SSEは長期接続を確立し、サーバーが頻繁なリクエストなしにリアルタイムでデータをクライアントにプッシュできるようにします。

SSEとWebSocketの比較

WebSocketはリアルタイムの双方向通信を可能にする別のウェブ技術であり、SSEとはいくつかの点で異なります。こちらがSSEとWebSocketの比較です:

データプッシュ方向:SSEはサーバーとクライアント間の一方通行通信であり、サーバーは積極的にデータをクライアントにプッシュできます。一方、WebSocketは双方向通信であり、サーバーとクライアント間でリアルタイムの双方向データ交換を可能にします。
接続確立:SSEは長いHTTPベースの接続を用いて、通常のHTTPリクエストとレスポンスを通じて接続を確立し、リアルタイムのデータプッシュを実現します。 WebSocketはWebSocket接続を確立することで双方向通信を可能にするカスタムプロトコルを使用します。
互換性:SSEはHTTPプロトコルに基づいているため、ほとんどの最新のブラウザで使用可能で、追加のプロトコルアップグレードを必要としません。 WebSocketはほとんどの現代のブラウザでサポートされていますが、特定のネットワーク環境では問題が生じることがあります。
適用シナリオ:SSEは、株価の更新やニュースのリアルタイムプッシュなど、サーバーがリアルタイムでクライアントにデータをプッシュするシナリオに適しています。 WebSocketはチャットアプリケーションや複数人による共同編集など、リアルタイムの双方向通信が必要なシナリオに適しています。
あなたの具体的なビジネスニーズやシナリオに応じて、SSEかWebSocketのどちらを選ぶかは実際のニーズによります。クライアントに一方向にデータを送るサーバーだけで、シンプルかつ互換性を保ちたいなら、SSEは良い選択肢です。双方向通信を実現したい場合や、より高度な機能や制御が必要な場合、WebSocketの方が適しているかもしれません。

SSEイベントストリーム形式

イベントストリームとは、UTF-8形式でエンコードされるべき単純なテキストデータのストリームです。イベントストリームメッセージは2つの改行で区切られています。コロンで始まる行動コメント欄は無視されます。各フィールドはフィールド名、コロン、そしてそのフィールドの値のテキストデータで表されます。

フィールドは以下の通りです:

出来事: イベントタイプを識別するための文字列です。この文字列が指定されている場合、ブラウザは指定されたイベント名のイベントを適切なリスナーにディスパッチします。クライアントは指定されたイベントを聞くためにaddEventListener()を使うべきです。メッセージにイベント名が指定されていない場合、オンメッセージハンドラを呼び出すことができます。
データ: メッセージのデータフィールド。 EventSourceがdata:で始まる複数の連続行を受け取ると、それらを連結し、その間に改行を挿入します。末尾のラインブレイクは削除されます。
身分証明書: Event IDは現在のEventSourceオブジェクトの内部プロパティ「Last Event ID」のプロパティ値となります。
リトライ再びつながる時だ。サーバーへの接続が切れた場合、ブラウザは指定された時間待ち、その後再接続を試みます。これはミリ秒単位で再接続までの時間を指定する整数でなければなりません。非整数の値は指定されている場合、その体は無視されます。

EventSourceインスタンス

EventSourceインターフェースは、ウェブコンテンツとサーバー間のインターフェースでイベントを送信します。

EventHandlerプロパティ

接続が開いているときにEventSource.onopenが呼び出されます。
EventSource.onmessageは、イベント属性のないメッセージが受信された場合に呼び出されます。
EventSource.onerrorは接続例外時に呼び出されます。

SSEサーバー(ASP.NET コア)

.NET 8で新しい ASP.NET Coreプロジェクトを作成し、コントローラーコードは以下の通りです:

ログインが見えます。

リンクを確立するクライアントに対しては、2間隔ごとにクライアントにメッセージを送信します。

SSEクライアント

クライアントコードを「ビュー」ページでhtmlとjsで書くようにしてください。

ログインが見えます。

プロジェクトは以下の効果で始めます。

参考：
ハイパーリンクのログインが見えます。
ハイパーリンクのログインが見えます。
ハイパーリンクのログインが見えます。

クズども · 2024年4月5日 12:03:28に投稿

デフォルトのブラウザEventSource APIでは、許可されるリクエストの種類にいくつかの制限があります。パスできるパラメータURLは、withCredentialsのみであり、したがって:

リクエスト本文はパスできません:リクエストを実行するために必要なすべての情報をURLにエンコードしなければなりません。URLはほとんどのブラウザで2000文字に制限されています。
カスタムリクエストヘッダーは渡せません
GETリクエストは行えず、他の方法を指定することはできません。
接続が切断されると、リトライポリシーをコントロールできません。ブラウザは数回静かにリトライしてから停止し、堅牢なアプリケーションとしては不十分です。

fetch-event-source(イベント・ソース)

このライブラリは、サーバー送信イベントを使用するためのFetch APIに基づく代替インターフェースを提供しています。イベントストリーム形式と完全に互換性があるので、すでにこれらのイベントを配信するサーバーがあれば、以前通り利用できます。しかし、今ではリクエストや応答に対してよりコントロールができます

ハイパーリンクのログインが見えます。

グッドタイム · 2024年11月14日 14:34:25に投稿

学んだ

クズども · 2024年12月25日 16:36:44 に投稿

小さなスラグ 2024年4月5日 12:03に投稿
デフォルトのブラウザEventSource APIは、許可されるリクエストの種類にいくつかの制限を課しています。パスできるパラメータURLはwithCredentia ...

NPMパッケージをブラウザ対応のJavaScriptスクリプトにコンパイルします
https://www.itsvse.com/thread-10762-1-1.html

クズども · 2024年12月25日 16:48:45に投稿

SSE (2) ブラウザタブ切り替え後のフェッチイベントソース再接続問題
https://www.itsvse.com/thread-10906-1-1.html

[.NET Core] SSE(1)は ASP.NET コアをSSEサーバーとして使用しています

関連記事

閲覧したセクション