Web 平台上，Express SDK 是否支持断线重连机制？

ZEGO Web SDK 支持断线重连机制。断线重连，是为保证用户在因一些异常原因，导致房间或推拉流断开后，能够自行恢复的机制。本文将介绍房间重连、推流重连、拉流重连三种情况下的 SDK 的逻辑处理，以及应对常见异常断开的处理方法。

1 重连逻辑说明

1.1 房间重连

用户登录房间后，如果因网络信号问题或网络类型切换问题，导致的与房间断开连接，SDK 内部会进行自动重连。

用户可通过监听 roomStateChanged 回调，实时监控自己在本房间内的连接状态。在登录房间时将参数 config 中的 userUpdate 设置为 “true” 的前提下，房间内的其他用户可通过 roomUserUpdate 回调获取到某用户连接状态变化的通知。

房间状态回调

房间状态示意图

房间断连后重连的情况有如下三种：

情况一：在服务端判断用户 A 心跳超时前重连成功

如果用户 A 短暂断线，但是在 90s 内重连成功了，那么用户 B 不会收到 roomUserUpdate 的回调通知。

• T0 = 0s：用户 A 的 SDK 收到客户端发起的 loginRoom 请求。
• T1 ≈ T0 + 120 ms：通常在调用 loginRoom 120 ms 后，客户端可以加入房间。加入房间过程中，用户 A 的客户端会收到 2 次 roomStateChanged 回调，分别通知客户端正在连接房间（logining）以及连接房间成功（logined）。
• T2 ≈ T1 + 100 ms：因网络传输延迟，用户 B 约在 100 ms 后收到 roomUserUpdate 回调以通知客户端用户 A 加入房间。
• T3：某个时间点，用户 A 因网络断开等原因导致上行网络变差。SDK 会尝试重新加入房间，同时客户端会收到 roomStateChanged 回调以通知客户端用户 A 正在断线重连。
• T5 = T3 + time（小于 90s）：用户 A 在重连时间内恢复网络，重连成功。会收到 roomStateChanged 回调以通知客户端用户 A 重连成功。

情况二：在服务端判断用户 A 心跳超时后重连成功：

• T0、T1、T2、T3 时刻的情况同“情况一：在服务端判断用户 A 心跳超时前重连成功”中的 T0、T1、T2、T3。
• T4' ≈ T3 + 90s：用户 B 此时收到 roomUserUpdate 回调以通知 用户 A 已断线。
• T5' = T3 + time（大于 90s，小于 5 min）：用户 A 在重连时间内恢复网络，重连成功。此时客户端会收到 roomStateChanged 回调以通知客户端用户 A 重连成功。
• T6' ≈ T5' + 100 ms：因网络传输延迟，用户 B 约在 100 ms 后收到 roomUserUpdate 回调以通知客户端用户 A 重连成功。

情况三：用户 A 重连失败：

• T0、T1、T2、T3 时刻的情况同“情况一：在服务端判断用户 A 心跳超时前重连成功”中的 T0、T1、T2、T3。
• T4'' ≈ T3 + 90s：用户 B 此时收到 roomUserUpdate 回调以通知 用户 A 已断线。
• T5'' = T3 + 5 min：如果用户 A 连续 5 min 无法重新加入房间，SDK 不再继续尝试重新连接。用户 A 将会收到 roomStateChanged 回调以通知客户端断开连接。

1.2 推流重连

在用户推流过程中，如果因网络信号问题或网络类型切换问题，导致的推流不成功，SDK 内部会进行自动重连。

若所有推流节点都尝试了仍不成功，用户将会收到 publisherStateUpdate 回调。“state” 为 NO_PUBLISH，且 “errorCode” 不为 “0”，表示 SDK 内部重连已失败，具体错误请根据 “errorCode” 的值进行判断，可参考 常见错误码。此时，业务侧可以考虑等待几秒后（比如 3 ～ 5 秒）开始重新推流，但是不要不断地进行重试，导致陷入死循环。

推流状态回调

1.3 拉流重连

在用户拉流过程中，如果因网络信号问题/网络类型切换问题，导致的拉流不成功，SDK 内部会进行自动重连。

若所有拉流节点都尝试了仍不成功，用户将会收到 playerStateUpdate 回调，“state” 为 NO_PLAY，且 “errorCode” 不为 “0”，表示 SDK 内部重连已失败，具体错误请根据 “errCode” 的值进行判断，可参考 常见错误码。此时，业务侧可以考虑等待几秒后(比如 3 ～ 5 秒)开始重新拉流，但是不要不断地进行重试，导致陷入死循环。

拉流状态回调

2 处理异常断开

2.1 主播端断网时的处理

SDK 会自动检测主播的网络情况，当检测到主播断网时，会自动暂停推流。如果网络在 300 秒内恢复正常，SDK 会自动重新推流。

断网 90 秒后，如果网络没有恢复，房间内的所有用户会收到 roomStreamUpdate 回调中的“流删除”通知，观众可在收到此回调时，调用 stopPlayingStream 接口停止拉流。如果 SDK 重试推流成功，房间内的所有用户会收到 roomStreamUpdate 回调中的“流新增”通知，观众可在收到此回调时，调用 startPlayingStream 重新开始拉流。

2.2 主播端网络异常时观众端如何处理

主播端断网时，观众端是无法监控到的。此时，观众端无法正常拉流，SDK 内部会自动重试拉流，如果重试后仍然拉不到流，观众端将会收到 playerStateUpdate 回调，回调中的 “errorCode” 不为 “0”，建议观众端间隔一段时间（比如 3 秒后）后再次进行拉流。

在 SDK 内部会自动重试拉流的过程中，针对主播端的情况，可做以下处理：

• 如果主播端网络恢复正常，重试拉流成功，观众端即可正常进行拉流。
• 如果主播端网络一直没有恢复，主播端断网的 90 秒后，观众端会收到 roomStreamUpdate 回调中的“流删除”通知，观众端可在收到此回调时，调用 stopPlayingStream 接口停止拉流。
• 如果后续主播端恢复正常且成功重新推流后，观众端可在收到 roomStreamUpdate 回调中的“流新增”通知时，调用 startPlayingStream 重新开始拉流。

2.3 主播端浏览器进程被杀或者页面崩溃时观众端如何处理

主播端浏览器进程被杀或者页面崩溃的情况下，主播端在 90 秒时仍未开播，观众端会收到 roomStreamUpdate 回调中的“流删除”通知，针对 90 秒之内和 90 秒后主播开播情况，可做以下处理。

• 90 秒内，如果主播再次开播，房间内的观众会先收到 roomStreamUpdate 回调中的“流删除”通知，此时需调用 stopPlayingStream 接口停止拉流，之后会收到 roomStreamUpdate 回调中的“流新增”通知，此时需调用 startPlayingStream 接口重新拉流。
• 90 秒后，如果主播仍然没有推流，房间内的观众会收到 roomStreamUpdate 回调中的“流删除”通知，此时调用 stopPlayingStream 停止拉流即可。

如果后续主播端恢复正常且成功重新推流后，观众端可在收到 roomStreamUpdate 回调中的“流新增”通知时，调用 startPlayingStream 重新开始拉流。