1. Socket.Dの主な特徴
まず、Scoket.D は効率的なバイナリ ネットワーク通信プロトコルです (公式声明では、イベントとセマンティックに基づいたネットワークです)メッセージ フロー アプリケーション プロトコル)、多くのシナリオで使用できます。次に、Scoket.D は穏やかに反応性です (コールバック スタイルを使用)。
1. 3つの通信モード
- send 送信するだけ（送信後は気にしない）
このリクエストに対する応答メッセージを送信せずにリクエストを送信します。これは、埋め込まれたポイントの監視、ログレポートなどに適しています。このシナリオでは、受信は必要なく、いくつかのリクエストが失われても問題ありません。
- sendAndRequest (送信とリクエスト、「応答」を求める)
要求メッセージを送信すると、応答側はそれを受信した後に応答メッセージを返します。従来の HTTP は典型的な sendAndRequest です。
- sendAndSubscribe (送信して購読、N 個の「返信」を受信可能)
サブスクリプション メッセージを送信すると、応答側は受信後に N 個の応答メッセージを送り返します。従来の MQ は通常、sendAndSubscribe です。
2. 双方向会話の双方向監視
サーバーはクライアントから送信されたメッセージをリッスンでき、クライアントもサーバーから送信されたメッセージをリッスンできます。形成されたセッションは、相互にメッセージを送信することもできます。
3. その他
- コンパクトで効率的なバイナリ プロトコル
- ディスカッションやイベントもあります
- 多重化
- 柔軟なトランスポート層スイッチング: TCP/UDP/WebSocket など。
- 高度な自動採点機能をサポート
4. 他のプロトコルとの比較
それぞれのプロトコルの利点が純化されているように感じます。シンプルだけどパワフル、とても未来的！
| 項目を比較する | ソケット.d | http | ウェブソケット | ソケット | ソケット.io |
|---|---|---|---|---|---|
| メッセージの送信 (Qos0) | 持っている | なし | 持っている | 持っている | 持っている |
| 送信とリクエスト (Qos1) | 持っている | 持っている | なし | 持っている | なし |
| 送信して購読する | 持っている | なし | なし | 持っている | なし |
| 返信または返答 | 持っている | 持っている | なし | 持っている | なし |
| 単一接続の双方向通信 | 持っている | なし | はい（不便） | 持っている | はい（不便） |
| データシャーディング | 持っている | / | なし | 持っている | 持っている |
| 切断後の自動再接続 | 持っている | / | なし | 持っている | 持っている |
| メタ情報 | 持っている | 持っている | なし | 持っている | なし |
| イベント（またはパス）があります | 持っている | 持っている | なし | なし | 持っている |
| フロー (またはメッセージの相関関係) がある | 持っている | なし | なし | 持っている | なし |
| ブローカーモードクラスター | 持っている | なし | なし | 持っている | なし |
| 非同期 | 非同期 | 同期する | 非同期 | 非同期 | 非同期 |
| インターフェースの経験 | クラシック | クラシック | クラシック | レスポンシブ (複雑) | クラシック |
| 基本的なトランスポートプロトコル | TCP、UDP、WS | tcp | http | TCP、UDP、WS | うーん |
2. Socket.D の内部実装
1. フレーム設計
socket.d はフレーム単位で送信します。また、大きなフレームは送信のために自動的に小さなフレームに分割され (16 MB を超える場合は自動的に分割および再組み立てされ、サイズは設定可能)、受信側に到着した後に自動的に集約されます。
- フレームの論理構造
frame: {flag, message: {sid, event, entity: { metaString, data}}}
フレームのデータ論理構造: フレーム内にはフラグとメッセージがあり、メッセージにはストリーム識別子、イベント、およびエンティティがあり、エンティティにはメタ情報文字列とデータがあります。
- 完全な標準フレームコード
[len:int][flag:int][sid:str(<64)][\n][event:str(<512)][\n][metaString:str(<4k)][\n][data:byte(<16m)]
| 分野 | タイプ | サイズ | 説明する |
|---|---|---|---|
| のみ | 整数 | 4バイト | フレーム長 (独自の 4 バイトのプレースホルダーを含む) |
| フラグ | 整数 | 4バイト | フラグ（プロトコル命令に相当） |
| シド | 弦 | 64バイト以内 | ストリームID。格式为： guid |
| イベント | 弦 | 512バイト以内 | イベント。格式为：可见字符 string |
| メタ文字列 | 弦 | 4Kb以内 | メタ情報文字列。格式为：通用的 uri queryString |
| データ | バイト[] | 16Mb以内 | データ。格式为： byte[] |
注：UDP伝送を使用する場合、フレーム長は2kを超えることはできません（実際には1.4kを超えることはできないと聞きました）
- 補助フレームコード（Ping、Pong、Close）を簡略化し、メッセージ部分を削除
[len:int][flag:int]
2. データ エンティティ —— エンティティ
開発者は通常、フレームに基づいてエンティティと接触します。エンティティは HTTP メッセージに似ており、リクエストまたはレスポンスにすることができます。次の 2 つの部分で構成されます。
- MetaString HTTP ヘッダーに似たメタ情報文字列。形式: 文字列
- データ データ。HTTP ボディに似ています。形式: バイナリ
3. 遊び方
Socket.D にはさまざまな方法があります。従来の RPC は問題ありません。IM にも適しています。MQ の開発も非常に簡単です (FolkMQ<) a i =2>それを使用して開発されました)。特定の機能は、プロキシ処理やネットワーク侵入にも使用できます。たとえば、IoT シナリオでは、Xiao Ming は自宅にスマート エアコンを持っています。Xiao Ming は屋外で携帯電話の APP を介してエアコンのスイッチを制御したいと考えています。この制御の問題をエレガントに説明するにはどうすればよいでしょうか?最も洗練された解決策は、「Xiao Ming がエアコンのスイッチの API を呼び出す」です。
さらに、最も古典的なプレイ方法は Broker です。Broker は、サービスの公開とアクセスを容易にする「ソフト ルーティング」ソリューションに似ています。サービスを公開するには、ブローカーに接続するだけで済みます。呼び出し元は、従来の登録センター、ポート管理、その他の一般的なサービス管理方法を放棄して、リバース リクエストを通じてサービスを透過的にブローカーに転送できます。
4. Socket.D ブローカーについて
ブローカーには多くの利点があります. サービスの公開にはリスニング ポートやサイドカーが必要ありません. サービスの登録は zk や etcd などを使用せずに簡単になります. LoadBalance はよりシンプルかつ安全になります. リスニング ポートなしで攻撃するのは困難です.多くの欠点もあります。ネットワーク上に余分なホップがあり、パフォーマンスがある程度低下します。Broker は集中設計であり、通常のグローバル Nginx に似ています。ただし、Broker のエレガントな起動と停止は明らかにより複雑です。ブローカー クラスター全体のボトルネックなどによって制限されます。神があなたのためにドアを閉めるとき、神は必ずあなたのために窓を開けてくださいます。
3. レスポンシブプログラミングは難しいですか?
リアクティブ プログラミングは古いトピックであり、すでにどこにでも存在しており、Excel の SUM でさえ本質的にはリアクティブな思考です。応答性とは、本質的には変化に応答するデータの流れです。 Socket.D プロトコル自体はレスポンシブと呼ばれ、ネットワーク レベルに拡張されています。
ただし、リアクティブ インターフェイスは、一般のプログラマにとってはあまり使いやすいものではありません。 Socket.D は応答性がありますが、「クラシック コールバック インターフェイス」を使用します。
4. まとめ
Socket.D は、将来的に普及するであろう非常に興味深いネットワーク プロトコルです。問題解決のアイデアとデザインは新鮮です。ご興味がございましたら、公式 Web サイトにアクセスして詳細をご覧ください。