@ckk163 一个房间 9 个人吗？那我觉得不需要考虑带宽问题了。。

@ckk163 嗯，不过有个最大同时说话人数的限制，要不带宽真的是指数级的，目前限制在 5 个

@dslwind 一个发烧友同事找房子的时候真的在用电表测电压。。。

@ckk163 给你也进不去的，需要账号，你就想象成一个大型同性交友平台就好了。。

@ckk163 你可以试下上面我发的那两个开源项目，跟他们差不多

@ckk163 这个还真看不了。。不是独立的程序，是别的程序调用的，需要特定条件才能打开

@ckk163 ...那我会被开的

@lty1993 为了赶需求搞的，就我一个人弄了 3 个月。。现在一共就跑了两台服务器
你说的我研究下，多谢提醒

@lty1993 需求不一样吧，我这边要大量进行融合，每个房间都要多人同时说话，测了下扛不住

@ckk163 同步怎么办，语音实时性要求很高的，按你那么搞一个人说了一句话，下一句话不知道什么时候传过来，然后就各种断断续续的，还有每个人听到的声音的先后顺序都不一样怎么搞

@ckk163 参考 http://sourceforge.net/projects/voicechatter/
https://github.com/mumble-voip/mumble

@lty1993 事实上就是客户端混合，服务器混合处理不了那么多数据

@ckk163 p2p 要考虑的因素太多了，各种穿透，以国内的网络环境很麻烦，举个最简单的例子，一个 50 个人的房间，你要跟 49 个人说话， 2kB 每秒，也就是你需要 49x2=98kB 的上传带宽，国内的带宽大部分是上下行不对等的，标称 4m 的带宽也就 256kb 的上行，根本达不到要求

需求简单的话 2 、 3 个月可以搞定
5000 人大概 2-5MB 下行 50-100MB/s 上行（根据语音质量还有房间人数）
一台 4 核服务器可以跑 5 万人左右（优化好的话可以更多）

Cloning into 'xxxxx'...
Password for 'xxxxx':
remote: Counting objects: 1321, done.
remote: Compressing objects: 100% (998/998), done.
fatal: The remote end hung up unexpectedlyiB | 48.00 KiB/s
fatal: early EOF
fatal: index-pack failed

呵呵

完全看不到有纪念的意思，反正看着不舒服

@yyfearth 一些小网站直接用弱密码，泄露了不心疼