idea's blog

这是关于 C1000K 序列文章的第二篇, 在前一篇文章 构建C1000K的服务器(1) – 基础 中, 介绍了支持 C1000K 的 Linux 系统的内核参数调整和系统设置. 在本篇文章中, 将对一个真正的应用服务器做 C1000K 测试.

Comet 服务器是一类逻辑相对简单, 需要高并发连接的服务器. Comet 在网站系统中的应用非常广泛, 可以见这篇日志的介绍: http://www.ideawu.net/blog/archives/737.html.

HTTP 协议处理

要开发一个支持百万并发连接的 Comet 服务器, 我选择 C/C++ 语言, 当然还有其它的选择如 Erlang, Java 等. 对于一个只支持 long-polling Comet 服务器, 首先要具备解析 HTTP 协议的能力, 我选择 libevent 来处理 HTTP 协议.

Continue reading »

虽然 libevent HTTP 服务器可以给连接注册关闭回调, 但客户端强制断开连接时, 服务器并没有立即知道.

 evhttp_connection_set_closecb(req->evcon, on_close, NULL);

原来, libevent 在收到 HTTP 请求后, 就不再监听读事件了, 所以就不能通过 read() 返回 0 来知道连接断开, 只能通过 send() 导致 SIGPIPE 才能知道.

为了让服务器立即知道客户端的断开, 只需要重新监听 EV_READ 事件即可.

struct bufferevent *bev = evhttp_connection_get_bufferevent(req->evcon);
bufferevent_enable(bev, EV_READ);

Libevent 的文档非常少, 而且示例也很奇缺, 在 Google 里一搜, 还真找不到一两个. 这里贴一个最简单的利用 Libevent 2 HTTP 库, 作为客户端向服务器发起请求的例子.

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <evhttp.h>
#include <event2/event.h>
#include <event2/http.h>
#include <event2/bufferevent.h>

void http_request_done(struct evhttp_request *req, void *arg){
    char buf[1024];
    int s = evbuffer_remove(req->input_buffer, &buf, sizeof(buf) - 1);
    buf[s] = '\0';
    printf("%s", buf);
    // terminate event_base_dispatch()
    event_base_loopbreak((struct event_base *)arg);
}

int main(int argc, char **argv){
    struct event_base *base;
    struct evhttp_connection *conn;
    struct evhttp_request *req;

    base = event_base_new();
    conn = evhttp_connection_base_new(base, NULL, "127.0.0.1", 8080);
    req = evhttp_request_new(http_request_done, base);

    evhttp_add_header(req->output_headers, "Host", "localhost");
    //evhttp_add_header(req->output_headers, "Connection", "close");

    evhttp_make_request(conn, req, EVHTTP_REQ_GET, "/index.php?id=1");
    evhttp_connection_set_timeout(req->evcon, 600);
    event_base_dispatch(base);

    return 0;
}

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

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

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

Continue reading »

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 »

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 »