爲什麼搞個新協議？
2021年時，想爲 Solon 生態 提供一種 MVC 體驗的 Socket 和 WebSocket 開發方式。這個想法，要求消息“能路由”、“有元信息”、“可建立關聯性”。於是就開發了 Socket.D 早期版本（算是草案版）。經過兩年的實踐，其重新定義爲：
是想要有一種更簡單、更通用的通訊方式。簡單，且便適用任何場景和平臺（想是這麼想的啊）。而這，便以 Socket.D 協議作爲載體。一個簡單的、規範的，面向未來的網絡應用協議。
爲什麼不湊合用別人的呢?
前人，總有不如意啊。而後人總是站在前人的成果上，吸取優點避開缺點。
| 協議 | 不稱心的地方 |
|---|---|
| http | 單向通訊；只能同步響應 |
| websocket | 沒有應用語義，只有框架；需要二次定製 |
| rsocket | 純響應式接口太複雜；沒有事件；元信息爲二進制，無法固定標準。不通用 |
| socket.io | 沒有流；沒有元信息 |
Socket.D 具備它們的優點，又美好的避開了缺點。是，更具普世性的通用協議。
爲什麼不基於別人的呢?
Socket.D 作爲網絡應用協議，原則上可支持任意傳輸協議。目前適配有 TCP、UDP 之類的基礎傳輸協議；也適配有 WebSocket、KCP 之類有加工過的傳輸協議。未來還可能適配別的傳輸協議。
爲什麼要基於事件消息驅動？
網絡通信是異步的，消息驅動可建立起單個連接上的多路消息流，從而實現多路複用，一個連接同時多請求多響應。而基於事件，是讓消息可路由，可分類處理。這個就像 mq 協議的 topic。
爲什麼要元信息？
http 協議，就是因爲有元信息（它叫頭信息），玩出了各種花！有了元信息，就可以爲數據進行語義標註。就可以實現各種擴展的場景應用！
爲什麼要流？
連接上傳輸的數據即爲流。協議通過流標識（sid），爲傳輸來回的相關數據建立起關聯性。Socket.D 基於流而行成的接口交互模型：
| 接口 | 描述 | 說明 |
|---|---|---|
| send | 發送 | 相當於 Qos0 |
| sendAndRequest | 發送並請求。要求一個答覆 | 相當於 Qos1 |
| sendAndSubscribe | 發送並訂閱。可接收零個或多個答覆消息 | |
| reply | 答覆 | |
| replyEnd | 答覆結束 |
爲什麼是這樣的接口交互？
首先 http 的接口交互是最經典。Socket.D 算是對它的學習、補充和擴展。因爲我們是消息驅動的嘛，大家都是講發消息、發消息。所以用 send 開頭：
a) send 發送
發完後，不需要答覆。它是能帶來性能提升的，不僅是跳過了答覆而節省網絡使用，而且不需要等待響應或也不需要建立消息的流關聯。是 http 請求/響應模式的補充。
b) sendAndRequest 發送並請求。要求一個答覆
http 經典的請求/響應模式。不管在什麼時候都非常有用，必須支持
c) sendAndSubscribe 發送並訂閱。可接收多個答覆消息
也是 http 請求/響應模式 的擴展，它允許多個答覆消息被流回。可以看作是“collection”的響應，但不是將所有數據作爲單個答覆返回，而是將每個元素按順序返回。
適用的場景可能是：
- 獲取視頻列表
- 獲取目錄中的產品
- 逐行檢索文件
d) reply 答覆
配合 sendAndRequest，sendAndSubscribe 答覆消息
e) replyEnd 答覆結束
配合 sendAndSubscribe 答覆消息，並告知答覆結束了。
爲什麼規劃了多平臺多語言？
大型分佈式系統通常由不同的團隊使用各種技術和編程語言以模塊化的方式實現。這些模塊需要可靠地通信，支持快速、獨立的進化。在分佈式系統中，模塊間有效且可擴展的通信是一個關鍵問題。它會顯著影響用戶體驗的延遲以及構建和運行系統所需的資源量。
Socket.D 這麼好的協議，必須爭取讓所有的平臺和語言都能用上。參與這種問題的解決。