客户端用 Vue 框架写的,分了8个自定义组件:
container.vue 是其它组件的父组件,其中 WebRtcPeerSendRecv.vue 是共用组件,UserOpt 和OneToOneBoxContainer 组件用于一对一聊天,BroadcastRoomOpt 和 OneToManyBoxContainer 组件用于一对多聊天,MeetRoomOpt 和 ManyToManyBoxCantainer 组件用于多对多聊天。
组件还有几个没有列出;因为组件的设计非常不合理,我在基于这样的组件设计写代码很难;所以这部分就不详细说了。
分类的消息处理器均在各自的类别组件中进行注册。通用的消息处理器在 container 中进行注册;总之,要保证接收到服务端消息时,有对应的消息处理器进行处理。
客户端创建的webrtc 对象有 WebRtcPeerSendrecv
、WebRtcPeerSendonly
和WebRtcPeerRecvonly
三种模式,其区别如其名称所示。
wa … 更详细的,我写不下去了。
功能都已实现,但界面不太满意,待重新设计以后,再上截图吧(会附上详细的操作说明)。
这一系列文章到此结束了,花了一个多月时间,当然,中间还有其它工作要做;按照我所了解的来看,kms 单单只做媒体流的转发延迟还是非常低的,但如果要对流进行操作,便会非常卡了(我并不清楚这是否与我分配的资源有关)。在这期间,遇到了很多问题,不过官方文档都能很好的解决。
这里有一个设想,关于 KMS 集群搭建。使用 Nginx 进行负载均衡,保证需要进行通信的双方连接到同一 KMS 上。