Broker 模式

介于协议特点的“双向通讯”能力，Socket.D 的客户端与服务端同时具备“请求”与“响应”的能力。在这个能力的支持下，业务概念的客户端与服务端，都以 Client 的身份（可称为 Player），连入一个中心 Server（可称为 Broker）。Player 发送消息后，由 Broker 进行转发给另一个（或一批） Player。此为，Socket.D Broker 模式，也是一个天然的集群形态。

感观上像是，一批玩家（Player）连接加入到了一个（或多个）社交平台（Broker）。就像我们用微信（或QQ）那样，大家连入微信服务器，发消息时由微信服务器转发给另一个（或一批）用户。

架构特点

1、中心与环绕结构

所有 Player 端，连到一个或多个 Broker 中心（一般用两个或以上，构建高可用性）。Player 既发送消息，也可答复消息。

2、自带注册与发现中心

连入的 Player 都会有自己的名字（连接时用@参数为自己取名）。且 Broker 实时感应它们的连接状态（毫秒级）。相对传统第三方注册服务架构，反应极快。连接地址示例：

sd:tcp://127.0.0.1:8602?@=demoapp

定制时，还可以通过别的方式为服务取多个不同的名字。比如，消息中间件开发在订阅行为时给自己取多个名字。

3、无端口启动

Player 无端口启动。以技术客户端的身份，连入 Broker。相对传统架构，不需要暴露业务服务的端口，更安全。

4、四种 Broker 转发方式（或广播方式）

• 四种转发方式（单播，单播!，组播，广播）：

• 通过at方式进行转发，示例：

session.send("test", new StringEntity("hello").at("demoapp"));
session.send("test", new StringEntity("hello").at("demoapp!"));
session.send("test", new StringEntity("hello").at("demoapp*"));
session.send("test", new StringEntity("hello").at("*"));