服务器如何向客户机传送事件

随着群集中事件的生成，CRNP 服务器将这些事件传送到请求这些类型的事件的所有客户机。 发送过程包括向客户机的回叫地址发送一条 SC_EVENT 消息。 每个事件都是通过一个新的 TCP 连接传送的。

客户机登记事件类型后，服务器立即通过一条包含 ADD_CLIENT 或 ADD_EVENT 消息的 SC_CALLBACK_REG 消息向客户机发送该类型的最新事件。 这样客户机就可以了解发送后续事件的系统的当前状态。

当服务器启动客户机 TCP 连接时，服务器将通过该连接发送一条 SC_EVENT 消息， 然后执行全双工关闭。

例如，客户机将执行以下操作：

1. 等候服务器启动 TCP 连接

2. 接受来自服务器的传入连接

3. 等候 SC_EVENT 消息

4. 读取 SC_EVENT 消息

5. 接收服务器已关闭连接（从套接字读取 0 字节）的指示

6. 关闭连接

所有客户机都登记完成后，必须始终在各自的回叫地址（IP 地址和端口号）上侦听传入的事件传送连接。

如果服务器未能联系客户机以传送事件，将按照您指定的次数和时间间隔重新尝试传送事件。 如果所有尝试均未成功，将从该服务器的客户机列表中删除此客户机。 要接收更多事件，客户机还需要通过发送另一条包含 ADD_CLIENT 消息的 SC_CALLBACK_REG 消息重新登记。

如何保障事件的传送

群集中生成的事件具有一个全序，按照传送到每个客户机的顺序保存。 换句话说，如果群集中先生成事件 A，然后生成事件 B，那么客户机 X 将先接收事件 A， 然后接收事件 B。但是不会保存传送到所有客户机的事件的全序。 也就是说，客户机 Y 可以在客户机 X 接收到事件 A 之前接收事件 A 和事件 B。这样，速度慢的客户机将无法容纳传送到所有客户机的事件。

服务器传送的所有事件（子类的第一个事件和出现服务器错误后的事件除外）都是作为响应群集实际生成的事件而发生的，除非服务器遇到错误，导致丢失群集生成的事件。 这种情况下，服务器将为表示系统当前状态的每个事件类型生成一个事件。 每个事件都被发送到登记为对该事件类型感兴趣的客户机。

事件传送遵循“至少一次”的规则。 也就是说，允许服务器将同一个事件多次发送到一台客户机上。 这在服务器发生临时故障，恢复正常后无法判断客户机是否已接收到最新信息时特别有用。

SC_EVENT 消息的内容

SC_EVENT 消息包含群集中实际生成的消息，该消息已经过转换，符合 SC_EVENT XML 消息的格式要求。 下表描述了 CRNP 传送的事件类型，包括名称和值对、发行商和供应商。