为什么搞个新协议？

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 答复消息

d) replyEnd 答复结束

配合 sendAndSubscribe 答复消息，并告知答复结束了。

为什么规划了多平台多语言？

大型分布式系统通常由不同的团队使用各种技术和编程语言以模块化的方式实现。这些模块需要可靠地通信，支持快速、独立的进化。在分布式系统中，模块间有效且可扩展的通信是一个关键问题。它会显著影响用户体验的延迟以及构建和运行系统所需的资源量。

Socket.D 这么好的协议，必须争取让所有的平台和语言都能用上。参与这种问题的解决。