• 2013-09-05

    150行C代码的comet服务器

    Views: 33319 | 39 Comments

    Comet 技术就是常见的 Web 服务器"推"技术, 用于向网页实时地推送数据. 最常见的 Comet 技术应用在网页聊天, 当然还可以应用于很多的方面, 如微博更新, 热点新闻推送, 股票即时行情等等, 甚至是网页游戏!

    Comet 技术如此重要, 但市面上并没有真正流行通用的 Comet 服务器和解决方案, 比较知名的互联网公司大多是自己开发, 或者基于开源服务器进行二次开发, 例如基于 Jetty(一个开源 Java Web 容器), 而 Facebook 的聊天系统的 Comet 服务器是基于 Mochiweb(一个开源的 Erlang Web 服务器).

    当然还有比较知名的以 nginx 模块形式出现的 nginx-push-stream, 但根据实际使用经验, 这个模块无法稳定支撑 10 万个并发连接, 更别谈百万同时在线了. 这也是这个模块为什么没有被普遍大规模应用的原因.

    Continue reading »

    Posted by ideawu at 2013-09-05 21:42:36
  • 2013-08-10

    WebRTC C/C++ API 示例代码 – 播放和录音

    Views: 50906 | 3 Comments

    WebRTC 的音频引擎封装了音频设备的统一接口, 使用者不用关心代码是 Windows, Mac OS X, Linux , iOS 或者 Android 等平台. 这也是一件非常棒的事情, 这个封装如果抽取出来, 就是一个优秀的跨平台音频接口(Audio API).

    这里提供一个示例, 讲解如何使用 WebRTC 的 C/C++ API 进行录音和播放声音. 首先, 引入头文件:

    #include "webrtc/modules/audio_device/include/audio_device.h"
    

    Continue reading »

    Posted by ideawu at 2013-08-10 00:28:15 Tags: , , , , ,
  • 2013-08-05

    WebRTC源码架构浅析

    Views: 53517 | No Comments

    Google 在2010年花了6千8百万美元收购了大名鼎鼎的 Global IP Sound/Solutions (GIPS) 公司, 得到了它的 VoIP 相关技术的专利和软件. 第二年, Google就把这些软件开源了, 不过, 不是作为独立的软件, 而且也和原来的软件功能大不一样, 而是作为所谓的 WebRTC 方案的一部分.

    GIPS 主要是提供视频和语音引擎技术和开发包, 而 WebRTC 却要提供一揽子的多媒体聊天解决方案, 特别是嵌入到浏览器中, 使用 Web 相关技术(如 JavaScript, HTML5). 所以, WebRTC 的源码结构非常庞大, 单单是从 trunk 中获取的代码和数据就达到1.2G还多.

    不过, 如果明白了 WebRTC 的架构, 就可以从这份开源代码中摘出我们想要的部分. WebRTC 包含下面几个部分:

    1. 应用层, 即 WebRTC 技术. 此部分的技术主要是浏览器开发者需要, 但因为其是太过于顶层的应用技术, 过于偏向某一方面, 所以可取可不取.

    2. 网络层, 主要是 libjingle. libjingle 就是 Google Talk 所使用的网络框架. 但 libjingle 并没开源服务器端的代码和技术, 再者, 网络层的可替换性很强, 各家公司总是设计自己的私有网络协议和架构, 所以, libjingle 的作用就是作为一个学习的对象.

    3. 语音和视频引擎, 这部分才是原来 GIPS 公司的专利和核心技术! 所以, 要详细解读一番.

    Continue reading »

    Posted by ideawu at 2013-08-05 00:24:01 Tags: , , , , ,
  • 2013-07-17

    使用 jemalloc 编译过程出错的问题

    Views: 15466 | No Comments

    使用 jemalloc, 编译过程出现如下报错:

    /usr/include/stdlib.h:589: 错误:‘void* malloc(size_t) throw ()’ 的声明抛出不同的异常
    /usr/include/stdlib.h:592: 错误:‘void* calloc(size_t, size_t) throw ()’ 的声明抛出不同的异常
    /usr/include/stdlib.h:601: 错误:‘void* realloc(void*, size_t) throw ()’ 的声明抛出不同的异常
    /usr/include/stdlib.h:603: 错误:‘void free(void*) throw ()’ 的声明抛出不同的异常
    /usr/include/stdlib.h:617: 错误:‘void* valloc(size_t) throw ()’ 的声明抛出不同的异常
    

    再看 jemalloc 的 manpage, 原来, 是必须在 include jemalloc 之前先 include stdlib.h.

    #include <stdlib.h>
    #include <jemalloc/jemalloc.h>
    
    Posted by ideawu at 2013-07-17 13:54:15
  • 2013-07-02

    SSDB采用了多线程模型

    Views: 24010 | 1 Comment

    自从SSDB 1.5.2版本起, SSDB默认使用了多线程, 将所有写操作放在一个单独的线程中, 这样可以避免写操作阻塞读操作.

    在之前的版本, SSDB的网络模块采用基于epoll IO多路复用的单线程模型, 这种模型非常快速. 不过, 由于LevelDB的特性, 当写操作过快的时候, 合并(Compaction)线程无法及时地完成所有合并, 导致Level-0文件越积越多, 最终强制阻塞所有写操作.

    SSDB新版本采用了多线程模型, 可以避免写操作阻塞读操作. 但是, 因为LevelDB的特性, 写操作仍然可能相互阻塞. 但是, 大部分SSDB的用户不需要担心写操作相互阻塞的问题, 因为大部分的应用的写操作不会那么快.

    可能有读者会提出疑问, 既然多线程这么好, 为什么直到1.5.2版本才采用多线程机制呢? 其实, 在某些情况下, 多线程不一定比单线程程序快. 原来有两个: 一是线程竞争, 二是线程间同步.

    SSDB使用pipe在网络线程和工作线程之间进行通信. 使用pipe, 使得工作线程的结果也是可select的, 这样, 就可以在网络线程中使用select/epoll得查询工作线程, 当工作线程处理完一个任务时, 网络线程能立即将这个结果返回给客户端.

    不过, 经过测试, pipe至少有10us的延迟, 这对于一个高并发的数据库服务器的影响也是可观的.

    不管怎么样, 在牺牲了一点点写性能之后, SSDB的总体可响应能力得到了极大的提高, 在我的机器上仍然能得到20K ops的写速度.

    Posted by ideawu at 2013-07-02 19:30:29
  • 2013-06-28

    nginx-push-stream-module 笔记

    Views: 24899 | No Comments

    nginx-push-stream-module 模块可用于 comet, 服务器向浏览器实时推送消息. 这个模块功能和稳定性还不错, 只是没考虑和外部系统的接口, 所以扩展性比较差. 例如权限验证, 连接的建立和断开等基础信息和外部共享等, 都缺失.

    这里记录几个关键函数, 打算利用 syslog 和外部系统进行信息共享.

    连接建立事件

    ngx_http_push_stream_subscriber_handler();
    

    连接断开事件

    ngx_http_push_stream_cleanup_request_context();
    ngx_http_push_stream_worker_subscriber_cleanup_locked();
    
    Posted by ideawu at 2013-06-28 11:09:46 Tags: ,
|<<<2345678910>>>| 6/12 Pages, 68 Results.