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

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

1 重连逻辑说明

1.1 房间重连

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

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

房间状态回调

房间状态示意图

其中：

• T0 = 0s：ClientA 的 SDK 收到客户端发起的 loginRoom 请求。
• T1 ≈ T0 + 120ms：通常在调用 loginRoom 120 毫秒后，客户端可以加入房间。加入房间过程中，ClientA 的客户端会收到 roomStateChanged(ZegoRoomStateChangedReason.LOGINING, 0, extendedData, roomID) 和 roomStateChanged(ZegoRoomStateChangedReason.LOGINED, 0, extendedData, roomID) 回调，分别通知客户端正在连接房间以及连接房间成功。
• T2 ≈ T1 + 100ms：因网络传输延迟，ClientB 约在 100ms 后收到 roomUserUpdate(roomID, "ADD", userList) 回调以通知客户端 ClientA 加入房间。
• T3：某个时间点，ClientA 因网络断开等原因导致上行网络变差。SDK 会尝试重新加入房间，同时客户端会收到 roomStateChanged(ZegoRoomStateChangedReason.RECONNECTING, 1002051, extendedData, roomID) 回调以通知客户端 ClientA 正在断线重连。
• T4 ≈ T3 + 90S：ClientB 此时收到 roomUserUpdate(roomID, "DELETE", userList) 回调以通知 ClientA 已断线。
• T5 = T3 + time（小于 5 分钟）：ClientA 在重连时间内恢复网络，重连成功。此时客户端会收到 roomStateChanged(ZegoRoomStateChangedReason.RECONNECTED, 0, extendedData, roomID) 回调以通知客户端 ClientA 重连成功。
• T6 ≈ T5 + 100ms：因网络传输延迟，ClientB 约在 100ms 后收到 roomUserUpdate(roomID,"ADD", userList) 回调以通知客户端 ClientA 重连成功。
• T7 = T3 + 20min：如果 ClientA 连续 20 分钟无法重新加入房间，SDK 不再继续尝试重新连接。ClientA 将会收到 roomStateChanged(ZegoRoomStateChangedReason.RECONNECT_FAILED, 1002053, extendedData, roomID) 回调以通知客户端断开连接。

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 重新开始拉流。