基于webrtc的视频聊天室（一）之千里之行始于足下

在不采用流媒体的情况下，也能够实现视频聊天室；可这需要在客户端建立多个连接，对客户端要求很高（上行带宽以及浏览器编解码速度），所以引入 kurento 流媒体服务器来做中转，或许后续不仅仅只是做中转。

流媒体服务器的选择更多的是因为它的文档全面，并且有提供了 Java Client API ，之前也有了解过 licode ，但文档太少，部署就耗费了我太多时间，后面发现它只能基于 node.js 做开发，我就半途而弃之。

该聊天室能够实现的功能：

1. 一对一聊天：
2. 一对多聊天：
3. 群组聊天：
4. 多人聊天（后续补充的，已完成）
5. 录制 （后续补充的，已完成）
6. 回放 （后续补充的，已完成）

4,5,6 的详细介绍参考 <<基于webrtc的视频聊天室（五）之服务端设计>> 这篇博文吧，我便不再补充了。

功能会依次实现，但如果前期数据抽象以及交互未做好的话，再新增功能会非常麻烦，这就是程序的可拓展性了。所以，如何解耦程序中的重要组件就非常关键了。

程序的重要组件有如下三部分：

1. 消息：这里的消息是指客户端与服务端建立 websocket 连接后，需要通过消息来控制整个流程；包括了 sdp 协商 和 业务流程控制。
2. 人员：参与视频聊天的人员。
3. 域：域即房间的概念，分为一对一域（即两个人之间的聊天），一对多域（即直播间的概念），多对多域（即群组聊天的概念）

如果我能够将上述几个组件设计的很好的话，那么我的系统将会非常棒，至少它看起来不会像是一锅浆糊，哪怕浆糊也能填饱肚子。

这里只对如何处理组件间的交互进行描述，关于组件的具体设计，我觉得需要另起博文，才能显示出我对它的重视。

应用程序既然是通过websocket 连接进行消息处理的，那么整个程序的入口处（相对于客户）就在websockethandler 中了，即对消息的处理中。

那么 handler 中有用的数据是什么呢？应用程序与客户端建立websocket 连接的session 肯定不能少，具体如何去存，不做展开，这里做特别说明是因为我们需要知道 session数据 来源于哪里，便于后面对其进行封装时进行考虑。

handler 中需要关心的回调方法有三个，afterConnectionEstablished 、handleMessage 和 afterConnectionClosed，方法的具体功能则如其名称所示。

• afterConnectionEstablished 方法看起来作用不大，但如果我们加上websocket 握手拦截器的话，这样可以在建立连接之前要求用户将自己的信息（例如姓名），作为URL 参数 来与应用程序建立连接，那么我们就可以在这里知道当前请求建立连接的用户信息了，这样可以对应用程序的所有用户做在线统计或者展示在线用户。
• handleMessage 方法是关键，如果不做出任何改变的话，整个应用程序的流程控制都集中将集中在这里。
• afterConnectionClosed 销毁当前用户的各项数据，保证应用程序中存储的数据都是可用的。

handler 说完以后，发现好像就没什么了，因为所有的代码都将在 handleMessage 中开始展开。