文档-4 p2p音频流媒体会议系统基本框架_水月居

来源:百度文库 编辑:神马文学网 时间:2024/04/29 01:43:42
水月居
主页博客相册|个人档案
查看文章
文档-4 p2p音频流媒体会议系统基本框架
2006-07-22 16:48
花了两天的时间跟踪程序,感觉现在比开始明白了好多。
第一件事是要把昨天的讨论内容整理一下。
这个项目不属于我所在的组,是老孟他们的组做的,内容是p2p的多人音频聊天系统。我参见了昨天下午他们的讨论会,与会的还有廖小飞老师。
讨论的主要内容自然是关于这个系统的主框架,由他们的组员提出思路,廖小飞老师进行指点。
首先我和疑惑的一点是这个系统到底是不是一个p2p的系统。由于一定要有注册服务器的支持,因此这个系统我认为只是一个混合的系统。今天问了涂博士,他说大多数的系统都是这样的折中,因此第一个问题:我们在做一个cs-p2p混合系统。
我们来讨论一下框架。这个系统由这样几个部分组成:
1 。注册服务器: 他的主要任务是在节点加入时提供全局的节点信息和选路信息并要保存这些信息;保存已经存在的会议的信息。在比较小的系统,我们目前是假设有200人左右,因此所有节点的加入都要通过这个服务器。当节点数量很大的时候,我们会在整个系统中选出leader并且只维护这些leader的信息,其他的节点由各自的leader来维护。
2。会议发起人:这个人是整个会议的发起者,需要保存整个会议组全部会员的信息并负责发布这些信息。
3。会议参与者:这些人是会议的参与者,现在的工作主要是要维护自己的partner列表并进行定期的维护;为了防止partner的个数少于设定的最小值,每个peer都拥有后备的partner列表,这个列表是其他partner发送过来的,因此每个节点还要负责定时发送自己的parnter列表到其他的perter。下午和涂博士讨论了这个问题,我们都认为这样做会浪费资源,而且很可能会形成这样的局面,就是:你会发现自己和自己的partner的列表很相似,因此当某些节点失去连接的时候,可能大家的后备都不可用。因此可能要考虑接收partner列表的策略。或者按照涂博士提的建议,用goosip协议,但是关于这个协议的内容我还没有看,这篇文章准备在最近几天的时间里来阅读。
整个讨论是围绕如下几个方面展开的:
1。如何选路:这是个应用用选路的问题,在我们测试的时候很可能用不到这个算法,大家基本上是要做到直连的。由于系统目前不要求做到很大,因此可能要注册服务器来维护全局的节点信息来进行选路。这里廖小飞老师提出了几点:
1-1 统计方法 即是当系统运行了一断时间,某些peer会发现自己的性能比较稳定,这个时候他可以想服务器申请做为临时服务器,当某个peer1和另一个peer2进行ping的时候发现回应时间很长,这个时候可以想服务器请求,服务器可以维护一个临时的服务器列表直接把这个列表发送过去。按照统计的方法发现合适的中转站,这样可能在开始运行的时候性能不是很好,试探性的方法,可以借鉴。
1-2 中转要有限制,这里我们限制为一跳,即不是直连就是通过一个节点来转发,不允许通过两个或两个以上的节点进行转发。
2。如何维护列表:每个peer应该有自己的peer列表,问题是如何选择这些peer。
2-1 如果单纯的按照效率来选择,很可能我们选择的都是离我们很近的节点,而真正的数据可能不在我们这个范围而造成“孤岛”。
2-2 当节点离开的时候如何获得新的节点。如果向服务器请求,那么服务器的压力很大。因此我们考虑后备列表并定时更新。这个问题在上面讨论过,具体的实现我要看了相关文章之后才能给出比较合理的解释。
3。消息的处理:多线程VS消息队列
多线程的方法是经常用到的,但我们经常会遇到诸如互斥等问题,因此引进了消息队列的概念。在涂博士的程序中也是采用的这种方法。廖小飞老师提出了一点:
所有的消息处理都是“非阻塞”的。即我们要用状态机的思想,只处理消息的相应状态而不能等待。我们只能把一个需要等待的消息变成另一个等待态的消息并重新插入消息队列中来处理,这样我们才能更快速的处理消息而不至于造成消息阻塞。
4。消音处理:当某个人没有说话的时候,我们要通过某种途径停止这些无用信息包的传播,这样既可以减少网络流量,也可以提高通话质量。
5。消息编码:按照标准的编码方式,有包头,包体组成,具体内容尚需设计。
上面讨论了一些问题,觉得对我更进一步理解目前的程序很有好处。
今天的工作是调试某些逻辑错误。因为这个程序运行的时间偏长,涂博士提醒可能是partner的上界没有限定好,导致每个peer的partner很多,因此处理起来速度很慢。虽然听起来很简单,但是要在这样一个比较大的程序中找到这样的逻辑错也不容易。跟踪了好久,终于发现问题:
当一个peer在ping你以后,我们没有限定直接把他加为partner了,因此才导致这样的问题。
用了一个if-else就解决了。
虽然问题不难解决,但是跟踪调试的过程确实很伤脑筋。
类别:p2p流媒体模拟程序 | 浏览(24)