Libuv库概述

From： http://blog.chinaunix.net/uid-28458801-id-4464173.html

libuv 是 Node 的新跨平台抽象层，用于抽象 Windows 的 IOCP 及 Unix 的 libev。作者打算在这个库的包含所有平台的差异性。

特性：

    非阻塞 TCP 套接字
    非阻塞命名管道
    UDP
    定时器
    子进程生成
    通过 uv_getaddrinfo 实现异步 DNS
    异步文件系统 API：uv_fs_* 高分辨率时间：uv_hrtime
    正在运行程序路径查找：uv_exepath
    线程池调度：uv_queue_work
    TTY控制的ANSI转义代码: uv_tty_t
    文件系统事件现在支持 inotify, ReadDirectoryChangesW 和 kqueue。很快会支持事件端口：uv_fs_event_t

    进程间的 IPC 与套接字共享：uv_write2

 

已受支持的平台：

    Microsoft Windows 操作系统，如 Windows XP SP2。使用 Visual Studio 或 MinGW 构建
    Linux 2.6 使用 GCC 工具链
    MacOS 使用 GCC 或 XCode 工具链
    Solaris 121 或之后版本，使用 GCC 工具链

序言

本书由一系列 libuv 教程组成， libuv 是一个高性能事件驱动的程序库，封装了 Windows 和 Unix 平台一些底层特性，为开发者提供了统一的 API.

本书旨在涵盖 libuv 的主要特性, 并不是一份完整介绍 libuv 内部每个 API 和数据结构的指南, 官方文档 official libuv documentation 可以直接在 libuv 源码提供的头文件中找到.

本书还没有完成，某些章节可能不完整，但我希望在我不断完善本书同时，你也能够从中获益 :-)

本书为谁而写?

如果你正在阅读本书，你或许是:

1. 系统开发人员, 编写一些诸如守护进程(daemons), 网络服务程序或者客户端等底层应用, 你发现 libuv 的事件循环方式适合你的应用场景, 因此你决定使用 libuv.
2. Node.js 某一模块的作者, 决定使用 C/C++ 封装系统平台某些同步或者异步 API, 并将其暴露给 Javasript, 你可以在 node.js 上下文中只使用 libuv, 但你也需要参考其他资源, 因为本书并没有包括 v8/node.js 相关的内容.

本书假设你对 C 语言有了一定的了解。

背景

node.js 最初发起于 2009 年, 是一个可以让 Javascript 代码脱离浏览器的执行环境, libuv 使用了 Google 的 V8 执行引擎 和 Marc Lehmann 的 libev. Node.js 将事件驱动的 I/O 模型与适合该模型的编程语言(Javascript)融合在了一起, 随着 node.js 的日益流行, node.js 的开发者们也意识到应该让 node.js 在 Windows 平台下也能工作, 但是 libev 只能在 Unix 环境下运行. Windows 平台上与 kqueue(FreeBSD) 或者 (e)poll(Linux) 等内核事件通知相应的机制 是 IOCP, libuv 依据不同平台的特性(Unix 平台为 libev, Windows 平台为 IOCP) 给上层应用提供了统一基于 libev API 的抽象, 不过 node-v0.9.0 版本的 libuv 中 libev 的依赖已被移除, 参见: libev has been removed libuv 直接与 Unix 平台交互.

本书代码

本书所有代码均可以在 Github 上获取, Clone/Download 本书源码，然后进入到 code/ 目录执行 make 编译本书的例子. 书中的代码基于 node-v0.9.8 版本的 libuv, 为了方便读者学习，本书的源码中也附带了相应版本的 libuv，你可以在 libuv/ 目录中找到源码，libuv 会在你编译书中的例子时被自动编译。

Libuv 基础

libuv 采用了 异步 (asynchronous), 事件驱动 (event-driven)的编程风格, 其主要任务是为开人员提供了一套事件循环和基于I/O(或其他活动)通知的回调函数, libuv 提供了一套核心的工具集, 例如定时器, 非阻塞网络编程的支持, 异步访问文件系统, 子进程以及其他功能.

事件循环(Event loops)

在事件编程模型中, 应用程序通常会关注某些特定的事件, 并在事件发生后对其作出响应. 而收集事件或监控其他事件源则是 libuv 的职责, 编程人员只需要对感兴趣的事件注册回调函数, 在事件发生后 libuv 将会调用相应的回调函数. 只要程序不退出(被系统管理人员 kill 掉), 事件循环通常会一直运行, 下面是事件驱动编程模型的伪代码:

while there are still events to process:
    e = get the next event if there is a callback associated with e:
        call the callback

适用于事件驱动编程模型的例子如下:

• 文件已经准备好可写入数据.
• 某一 socket 上存在数据可读.
• 定时器已超时.

事件循环由 uv_run 函数封装, 在使用 libuv 编程时, 该函数通常在最后才被调用.

计算机程序最基本的活动是输入输出的处理, 而不是大量的数值计算, 而使用传统输入输出函数(read, fprintf 等)的问题是它们都是 阻塞 的. 将数据写入磁盘或者从网络读取数据都会消耗大量时间, 而阻塞函数直到任务完成后才返回, 在此期间你的程序什么也没有做, 浪费了大量的 CPU 时间. 对于追求高性能的程序而言, 在其他活动或者 I/O 操作在进行尽量让 CPU 不被阻塞.

标准的解决方案是使用线程, 每个阻塞的 I/O 操作都在一个单独的线程(或线程池)中启动, 当阻塞函数被调用时, 处理器可以调度另外一个真正需要 CPU 的线程来执行任务.

Libuv 采用另外一种方式处理阻塞任务, 即 异步 和 非阻塞 方式.大多数现代操作系统都提供了事件通知功能, 例如, 调用 read读取网络套接字时程序会阻塞, 直到发送者最终发送了数据(read 才返回). 但是, 应用程序可以要求操作系统监控套接字, 并在套接字上注册事件通知. 应用程序可以在适当的时候查看它所监视的事件并获取数据(若有). 整个过程是 异步 的, 因为程序在某一时刻关注了它感兴趣的事件, 并在另一个时刻获取(使用)数据, 这也是 非阻塞 的, 因为该进程还可以处理另外的任务. Libuv 的事件循环方式很好地与该模型匹配, 因为操作系统事件可以视为另外一种 libuv 事件. 非阻塞方式可以保证在其他事件到来时被尽快处理 [1].

Note

I/O 是如何在后台运行的不是我们所关心的, 但是由于我们计算机硬件的工作方式, 线程是处理器最基本的执行单元, thread as the basic unit of the , libuv 和操作系统通常会运行后台/工作者线程, 或者采用非阻塞方式来轮流执行任务.

Hello World

具备了上面最基本的知识后, 我们就来编写一个简单 libuv 的程序吧.该程序并没有做任何具体的事情, 只是简单的启动了一个会退出的事件循环.

#include  #include  int main() {
    uv_loop_t *loop = uv_loop_new();

    printf("Now quitting.\n");
    uv_run(loop, UV_RUN_DEFAULT); return 0;
}

该程序启动后就会直接退出, 因为你没有事件可处理. 我们可以使用 libuv 提供了各种 API 来告知 libuv 我们感兴趣的事件.

libuv 的默认事件循环(Default loop)

libuv 提供了一个默认的事件循环, 你可以通过 uv_default_loop 来获得该事件循环, 如果你的程序中只有一个事件循环, 你就应该使用 libuv 为我们提供的默认事件循环.

Note

node.js 使用默认事件循环作为它的主循环,如果你正在编写 node.js 的绑定, 你应该意识到这一点.

监视器(Watchers)

libuv 通过监视器(Watcher)来对特定事件进行监控, 监视器通常是类似 uv_TYPE_t 结构体的封装, TYPE 代表该监视器的用途, libuv 所有的监视器类型如下:

typedef struct uv_loop_s uv_loop_t;
typedef struct uv_err_s uv_err_t;
typedef struct uv_handle_s uv_handle_t;
typedef struct uv_stream_s uv_stream_t;
typedef struct uv_tcp_s uv_tcp_t;
typedef struct uv_udp_s uv_udp_t;
typedef struct uv_pipe_s uv_pipe_t;
typedef struct uv_tty_s uv_tty_t;
typedef struct uv_poll_s uv_poll_t;
typedef struct uv_timer_s uv_timer_t;
typedef struct uv_prepare_s uv_prepare_t;
typedef struct uv_check_s uv_check_t;
typedef struct uv_idle_s uv_idle_t;
typedef struct uv_async_s uv_async_t;
typedef struct uv_process_s uv_process_t;
typedef struct uv_fs_event_s uv_fs_event_t;
typedef struct uv_fs_poll_s uv_fs_poll_t;
typedef struct uv_signal_s uv_signal_t;

所有监视器的结构都是 uv_handle_t 的”子类”， 在 libuv 和本文中都称之为句柄( handlers ).

监视器由相应类型的初始化函数设置, 如下:

uv_TYPE_init(uv_TYPE_t*) 

某些监视器初始化函数的第一个参数为事件循环的句柄.

监视器再通过调用如下类型的函数来设置事件回调函数并监听相应事件:

uv_TYPE_start(uv_TYPE_t*, callback) 

而停止监听应调用如下类型的函数:

uv_TYPE_stop(uv_TYPE_t*) 

当 libuv 所监听事件发生后, 回调函数就会被调用. 应用程序特定的逻辑通常都是在回调函数中实现的, 例如, 定时器回调函数在发生超时事件后也会被调用, 另外回调函被调用时传入的相关参数都与特定类型的事件有关, 例如, IO 监视器的回调函数在发生了IO事件后将会收到从文件读取的数据.

空转(Idling)

接下来我们通过例子来讲述监视器的使用. 例子中空转监视器回调函数被不断地重复调用, 当然其中也有一些深层次的语言，我们将会在 工具集 进一步讨论, 但现在我们只是跳过具体细节. 我们只是使用了一个空转监视器回调来看看监视器的生命周期, 通过例子我们也可以了解到： 由于设置了监视器, 所以调用 uv_run() 是程序会阻塞, 空转监视器将会在计数器达到设定的值时停止(监视), uv_run() 会退出因为此时程序中没有活动的监视器了.

#include  #include  int64_t counter = 0; void wait_for_a_while(uv_idle_t* handle, int status) {
    counter++; if (counter >= 10e6)
        uv_idle_stop(handle);
} int main() {
    uv_idle_t idler;
    uv_idle_init(uv_default_loop(), &idler);
    uv_idle_start(&idler, wait_for_a_while);

    printf("Idling...\n");
    uv_run(uv_default_loop(), UV_RUN_DEFAULT); return 0;
}

文件系统

简单的文件读写是通过 uv_fs_* 函数族和与之相关的 uv_fs_t 结构体完成的.

libuv 提供的文件操作和 socket operations 并不相同. 套接字操作使用了操作系统本身提供了非阻塞操作, 而文件操作内部使用了阻塞函数, 但是 libuv 是在线程池中调用这些函数, 并在应用程序需要交互时通知在事件循环中注册的监视器.

所有的文件操作函数都有两种形式 - 同步 synchronous 和 asynchronous.

同步 synchronous 形式如果没有指定回调函数则会被自动调用( 阻塞的 ), 函数的返回值和 Unix 系统的函数调用返回值相同(调用成功通常返回 0, 若出现错误则返回 -1).

而异步 asynchronous 形式则会在传入回调函数时被调用, 并且返回 0.

读写文件

文件描述符可以采用如下方式获得:

int uv_fs_open(uv_loop_t* loop, uv_fs_t* req, const char* path, int flags, int mode, uv_fs_cb cb)

 

参数 flags 与 mode 和标准的 Unix flags 相同. libuv 会小心地处理 Windows 环境下的相关标志位(flags)的转换, 所以编写跨平台程序时你不用担心不同平台上文件打开的标志位不同。

关闭文件描述符可以使用:

int uv_fs_close(uv_loop_t* loop, uv_fs_t* req, uv_file file, uv_fs_cb cb)

与文件系统相关的操作的回调函数具有如下签名:

void callback(uv_fs_t* req);

让我们来看看 cat 命令的一个简单实现吧: 我们首先注册一个在文件打开时的回调函数 (顾名思义, 该函数将在文件打开时被调用).

void on_open(uv_fs_t *req) { if (req->result != -1) {
        uv_fs_read(uv_default_loop(), &read_req, req->result,
                   buffer, sizeof(buffer), -1, on_read);
    } else {
        fprintf(stderr, "error opening file: %d\n", req->errorno);
    }
    uv_fs_req_cleanup(req);
}

uv_fs_t 的 result 字段在执行 us_fs_open 时代表一个文件描述符, 如果文件成功被打开, 我们开始读取文件.

必须调用 uv_fs_req_cleanup() 来释放 libuv 内部使用的内存空间.

void on_read(uv_fs_t *req) {
    uv_fs_req_cleanup(req); if (req->result < 0) {
        fprintf(stderr, "Read error: %s\n", uv_strerror(uv_last_error(uv_default_loop())));
    } else if (req->result == 0) {
        uv_fs_t close_req; // synchronous uv_fs_close(uv_default_loop(), &close_req, open_req.result, NULL);
    } else {
        uv_fs_write(uv_default_loop(), &write_req, 1, buffer, req->result, -1, on_write);
    }
}

在调用 read 时, 你应该传递一个初始化的缓冲区, 在 read 回调函数被触发(调用之前), 该缓冲区将会被填满数据.

在 read 的回调函数中 result 如果是 0, 则读取文件时遇到了文件尾(EOF), -1 则代表出现了错误, 而正整数则是表示成功读取的字节数.

此处给你展示了编写异步程序的通用模式, uv_fs_close() 是异步调用的. 通常如果任务是一次性的, 或者只在程序启动和关闭时被执行的话都可以采用同步方式执行, 因为我们期望提高 I/O 效率, 采用异步编程时程序也可以做一些基本的任务并处理多路 I/O.. 对于单个任务而言性能差异可以忽略, 但是代码却能大大简化.

我们可以总结出真正的系统调用返回值一般是存放在 uv_fs_t.result.

写入文件与上述过程类似, 使用 uv_fs_write 即可. write 的回调函数在写入完成时被调用.. 在我们的程序中回调函数只是只是简单地发起了下一次读操作, 因此, 读写操作会通过回调函数连续进行下去.

void on_write(uv_fs_t *req) {
    uv_fs_req_cleanup(req); if (req->result < 0) {
        fprintf(stderr, "Write error: %s\n", uv_strerror(uv_last_error(uv_default_loop())));
    } else {
        uv_fs_read(uv_default_loop(), &read_req, open_req.result, buffer, sizeof(buffer), -1, on_read);
    }
}

错误值通常保存在 errno 并可以通过 uv_fs_t.errorno 获取, 但是被转换成了标准的 UV_* 错误码. 目前还没有方法直接从 errorno 解析得到错误消息的字符串表示.

由于文件系统和磁盘通常为了提高性能吞吐率而配置了缓冲区, libuv 中一次 ‘成功’ 的写操作可能不会被立刻提交到磁盘上, 你可以通过 uv_fs_fsync 来保证一致性.

我们再来看看 main 函数中设置的多米诺骨牌吧(原作者意指在 main 中设置回调函数后会触发整个程序开始执行):

int main(int argc, char **argv) {
    uv_fs_open(uv_default_loop(), &open_req, argv[1], O_RDONLY, 0, on_open);
    uv_run(uv_default_loop(), UV_RUN_DEFAULT); return 0;
}

 

文件系统相关操作(Filesystem operations)

所有的标准文件系统操作, 例如 unlink, rmdir, stat 都支持异步操作, 并且各个函数的参数非常直观. 他们和 read/write/open 的调用模式一致, 返回值都存放在 uv_fs_t.result 域. 完整的列表如下:

UV_EXTERN int uv_fs_close(uv_loop_t* loop, uv_fs_t* req, uv_file file,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_open(uv_loop_t* loop, uv_fs_t* req, const char* path, int flags, int mode, uv_fs_cb cb);

UV_EXTERN int uv_fs_read(uv_loop_t* loop, uv_fs_t* req, uv_file file, void* buf, size_t length, int64_t offset, uv_fs_cb cb);

UV_EXTERN int uv_fs_unlink(uv_loop_t* loop, uv_fs_t* req, const char* path,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_write(uv_loop_t* loop, uv_fs_t* req, uv_file file, void* buf, size_t length, int64_t offset, uv_fs_cb cb);

UV_EXTERN int uv_fs_mkdir(uv_loop_t* loop, uv_fs_t* req, const char* path, int mode, uv_fs_cb cb);

UV_EXTERN int uv_fs_rmdir(uv_loop_t* loop, uv_fs_t* req, const char* path,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_readdir(uv_loop_t* loop, uv_fs_t* req, const char* path, int flags, uv_fs_cb cb);

UV_EXTERN int uv_fs_stat(uv_loop_t* loop, uv_fs_t* req, const char* path,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_fstat(uv_loop_t* loop, uv_fs_t* req, uv_file file,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_rename(uv_loop_t* loop, uv_fs_t* req, const char* path, const char* new_path, uv_fs_cb cb);

UV_EXTERN int uv_fs_fsync(uv_loop_t* loop, uv_fs_t* req, uv_file file,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_fdatasync(uv_loop_t* loop, uv_fs_t* req, uv_file file,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_ftruncate(uv_loop_t* loop, uv_fs_t* req, uv_file file,
    int64_t offset, uv_fs_cb cb);

UV_EXTERN int uv_fs_sendfile(uv_loop_t* loop, uv_fs_t* req, uv_file out_fd,
    uv_file in_fd, int64_t in_offset, size_t length, uv_fs_cb cb);

UV_EXTERN int uv_fs_chmod(uv_loop_t* loop, uv_fs_t* req, const char* path, int mode, uv_fs_cb cb);

UV_EXTERN int uv_fs_utime(uv_loop_t* loop, uv_fs_t* req, const char* path, double atime, double mtime, uv_fs_cb cb);

UV_EXTERN int uv_fs_futime(uv_loop_t* loop, uv_fs_t* req, uv_file file, double atime, double mtime, uv_fs_cb cb);

UV_EXTERN int uv_fs_lstat(uv_loop_t* loop, uv_fs_t* req, const char* path,
    uv_fs_cb cb);

UV_EXTERN int uv_fs_link(uv_loop_t* loop, uv_fs_t* req, const char* path, const char* new_path, uv_fs_cb cb);

 

回调函数中应该调用 uv_fs_req_cleanup() 函数来释放 uv_fs_t 参数占用的内存.

缓冲区与流(Buffers and Streams)

libuv 中基本的 I/O 工具是流(uv_stream_t). TCP 套接字, UDP 套接字, 文件, 管道, 和进程间通信都可以作为 流 的子类.

流 (Streams) 通过每个子类特定的函数来初始化, 然后可以通过如下函数进行操作:

int uv_read_start(uv_stream_t*, uv_alloc_cb alloc_cb, uv_read_cb read_cb); int uv_read_stop(uv_stream_t*); int uv_write(uv_write_t* req, uv_stream_t* handle,
            uv_buf_t bufs[], int bufcnt, uv_write_cb cb);

 

基于流的函数比上面介绍的文件系统相关的函数更容易使用, libuv 在调用 uv_read_start 后会自动从流中读取数据, 直到调用了 uv_read_stop.

用于保存数据的单元被抽象成了 buffer 结构 – uv_buf_t. 它其实只保存了指向真实数据的指针(uv_buf_t.base) 以及真实数据的长度 (uv_buf_t.len). uv_buf_t 本身是轻量级的, 通常作为值被传递给函数, 真正需要进行内存管理的是 buffer 结构中的指针所指向的真实数据, 通常由应用程序申请分配并释放.

为了示范流的用法, 我们借助了(管道) uv_pipe_t , 这使得我们把本地文件变成了流[#]_. 下面是利用 libuv 实现的一个简单的 tee . 将所有的操作变成了异步方式后, 事件 I/O 的强大能力便展现出来. 两个写操作并不会阻塞对方, 但是我们必须小心地拷贝数据至缓冲区, 并确保在写入数据之前缓冲区不被释放.

该程序按照如下方式执行:

./uvtee <output_file> 

我们在指定的文件上打开了一个管道, libuv 的文件管道默认是双向打开的.

int main(int argc, char **argv) {
    loop = uv_default_loop();

    uv_pipe_init(loop, &stdin_pipe, 0);
    uv_pipe_open(&stdin_pipe, 0);

    uv_pipe_init(loop, &stdout_pipe, 0);
    uv_pipe_open(&stdout_pipe, 1);
    
    uv_fs_t file_req; int fd = uv_fs_open(loop, &file_req, argv[1], O_CREAT | O_RDWR, 0644, NULL);
    uv_pipe_init(loop, &file_pipe, 0);
    uv_pipe_open(&file_pipe, fd);

    uv_read_start((uv_stream_t*)&stdin_pipe, alloc_buffer, read_stdin);

    uv_run(loop, UV_RUN_DEFAULT); return 0;
}

若是 IPC 或命名管道, uv_pipe_init() 的第三个参数应该设置为 1, 我们会在 进程 一节对此作出详细解释. 调用 uv_pipe_open() 将文件描述符和文件关联在了一起.

我们开始监控标准输入 stdin. 回调函数 alloc_buffer 为程序开辟了一个新的缓冲区来容纳新到来的数据. read_stdin 也会被调用, 并且 uv_buf_t 作为调用参数.

uv_buf_t alloc_buffer(uv_handle_t *handle, size_t suggested_size) { return uv_buf_init((char*) malloc(suggested_size), suggested_size);
} void read_stdin(uv_stream_t *stream, ssize_t nread, uv_buf_t buf) { if (nread == -1) { if (uv_last_error(loop).code == UV_EOF) {
            uv_close((uv_handle_t*)&stdin_pipe, NULL);
            uv_close((uv_handle_t*)&stdout_pipe, NULL);
            uv_close((uv_handle_t*)&file_pipe, NULL);
        }
    } else { if (nread > 0) {
            write_data((uv_stream_t*)&stdout_pipe, nread, buf, on_stdout_write);
            write_data((uv_stream_t*)&file_pipe, nread, buf, on_file_write);
        }
    } if (buf.base)
        free(buf.base);
}

 

 

此处使用标准的 malloc 已经可以足够, 但是你也可以指定其他的内存分配策略. 例如, node.js 使用自己特定的 slab 分配器.

在任何情况下出错, read 回调函数 nread 参数都为 -1. 出错原因可能是 EOF(遇到文件尾), 在此种情况下我们使用 ‘’uv_close()’’ 函数关闭所有的流, uv_close() 会根据所传递进来句柄的内部类型来自动处理. 如果没有出现错误, nread 是一个非负数, 意味着我们可以向输出流中写入 nread 字节的数据. 最后记住一点, 缓冲区 buffer 的分配和释放是由应用程序负责的, 所以记得释放不再使用的内存空间.

typedef struct {
    uv_write_t req;
    uv_buf_t buf;
} write_req_t; void free_write_req(uv_write_t *req) {
    write_req_t *wr = (write_req_t*) req;
    free(wr->buf.base);
    free(wr);
} void on_stdout_write(uv_write_t *req, int status) {
    free_write_req(req);
} void on_file_write(uv_write_t *req, int status) {
    free_write_req(req);
} void write_data(uv_stream_t *dest, size_t size, uv_buf_t buf, uv_write_cb callback) {
    write_req_t *req = (write_req_t*) malloc(sizeof(write_req_t));
    req->buf = uv_buf_init((char*) malloc(size), size);
    memcpy(req->buf.base, buf.base, size);
    uv_write((uv_write_t*) req, (uv_stream_t*)dest, &req->buf, 1, callback);
}

write_data() 将读取的数据拷贝一份至缓冲区 req->buf.base, 同样地, 当 write 完成后回调函数被调用时, 该缓冲区也并不会被传递到回调函数中, 所以, 为了绕过这一缺点, 我们将写请求和缓冲区封装在 write_req_t 结构体中, 然后在回调函数中解封该结构体来获取相关参数.

文件变更事件(File change events)

现代操作系统都提供了 API 用来在单独的文件或文件夹上设置监视器, 当文件被修改时应用程序会得到通知, libuv 也封装了常用的文件变更通知程序库 [1]. 这是 libuv 中最不一致的部分了, 文件变更通知系统本身在不同的系统中实现起来差别非常大, 因此让所有的事情在每个平台上都完美地工作将变得异常困难, 为了给出一个示例，我写了一个简单的工具, 该函数按照如下命令行运行， 并监视指定的文件.

./onchange [file2] ...

文件变更通知通过 uv_fs_event_init() 启动:

while (argc-- > 2) {
        fprintf(stderr, "Adding watch on %s\n", argv[argc]);
        uv_fs_event_init(loop, (uv_fs_event_t*) malloc(sizeof(uv_fs_event_t)), argv[argc], run_command, 0);
    }

 

第三个参数是实际监控的文件或者文件夹, 最后一个参数 flags 可取值如下:

 UV_FS_EVENT_WATCH_ENTRY = 1,
 UV_FS_EVENT_STAT = 2,
 UV_FS_EVENT_RECURSIVE = 3

 

若设置 UV_FS_EVENT_WATCH_ENTRY 和 UV_FS_EVENT_STAT 不做任何事情(目前). 设置了 UV_FS_EVENT_RECURSIVE 将会监视子文件夹(需 libuv 支持).

回调函数将接受以下参数:

1. uv_fs_event_t *handle - 监视器. filename

   字段是该监视器需要监视的文件.

2. const char *filename - 如果监视目录, 则该参数指明该目录中发生了变更的文件,

   在 Linux 和 Windows 平台上可以是非 null.

3. int flags - UV_RENAME 或 UV_CHANGE.

4. int status - 目前为 0.

我们的例子只是简单地打印出参数, 并通过 system 函数运行指定命令.

void run_command(uv_fs_event_t *handle, const char *filename, int events, int status) {
    fprintf(stderr, "Change detected in %s: ", handle->filename); if (events == UV_RENAME)
        fprintf(stderr, "renamed"); if (events == UV_CHANGE)
        fprintf(stderr, "changed");

    fprintf(stderr, " %s\n", filename ? filename : "");
    system(command);
}

 

网络

libuv 的网络接口与 BSD 套接字接口存在很大的不同, 某些事情在 libuv 下变得更简单了, 并且所有接口都是都是非阻塞的, 但是原则上还是一致的. 另外 libuv 也提供了一些工具类的函数抽象了一些让人生厌的, 重复而底层的任务,比如使用 BSD 套接字结构来建立套接字, DNS 查询, 或者其他各种参数的设置.

libuv 中在网络 I/O 中使用了 uv_tcp_t 和 uv_udp_t 两个结构体.

TCP

TCP 是一种面向连接的流式协议, 因此是基于 libuv 的流式基础架构上的.

服务器(Server)

服务器端的 sockets 处理流程如下:

1. uv_tcp_init 初始化 TCP 监视器.
2. uv_tcp_bind 绑定.
3. 在指定的监视器上调用 uv_listen 来设置回调函数, 当有新的客户端连接到来时, libuv 就会调用设置的回调函数.
4. uv_accept 接受连接.
5. 使用 stream operations 与客户端进行通信.

以下是一个简单的 echo 服务器的例子:

int main() {
    loop = uv_default_loop();

    uv_tcp_t server;
    uv_tcp_init(loop, &server); struct sockaddr_in bind_addr = uv_ip4_addr("0.0.0.0", 7000);
    uv_tcp_bind(&server, bind_addr); int r = uv_listen((uv_stream_t*) &server, 128, on_new_connection); if (r) {
        fprintf(stderr, "Listen error %s\n", uv_err_name(uv_last_error(loop))); return 1;
    } return uv_run(loop, UV_RUN_DEFAULT);
}

你可以看到辅助函数 uv_ip4_addr 用来将人为可读的字符串类型的 IP 地址和端口号转换成 BSD 套接字 API 所需要的 struct sockaddr_in 类型的结构. 逆变换可以使用 uv_ip4_name 来完成.

对于 IPv6 来说应该使用 uv_ip6_* 形式的函数.

大部分的设置(setup)函数都是普通函数, 因为他们都是 计算密集型(CPU-bound), 直到调用了 uv_listen 我们才回到 libuv 中回调函数风格. uv_listen 的第二个参数 backlog 队列长度 – 即连接队列最大长度.

当客户端发起了新的连接时, 回调函数需要为客户端套接字设置一个监视器, 并调用 uv_accept 函数将客户端套接字与新的监视器在关联一起. 在例子中我们将从流中读取数据.

void on_new_connection(uv_stream_t *server, int status) { if (status == -1) { // error! return;
    }

    uv_tcp_t *client = (uv_tcp_t*) malloc(sizeof(uv_tcp_t));
    uv_tcp_init(loop, client); if (uv_accept(server, (uv_stream_t*) client) == 0) {
        uv_read_start((uv_stream_t*) client, alloc_buffer, echo_read);
    } else {
        uv_close((uv_handle_t*) client, NULL);
    }
}

剩余部分的函数与上一节流式例子中的代码相似, 你可以在例子程序中找到具体代码, 如果套接字不再使用记得调用 uv_close 关闭该套接字. 如果你不再接受连接, 你可以在 uv_listen 的回调函数中关闭套接字.

客户端(Client)

在服务器端你需要调用 bind/listen/accept, 而在客户端你只需要调用 uv_tcp_connect. uv_tcp_connect 使用了与 uv_listen 风格相似的回调函数 uv_connect_cb 如下:

uv_tcp_t socket;
uv_tcp_init(loop, &socket);

uv_connect_t connect; struct sockaddr_in dest = uv_ip4_addr("127.0.0.1", 80);

uv_tcp_connect(&connect, &socket, dest, on_connect);

建立连接后会调用 on_connect.

UDP

User Datagram Protocol 提供了无连接, 不可靠网络通信协议, 因此 libuv 并不提供流式 UDP 服务, 而是通过 uv_udp_t 结构体(用于接收)和 uv_udp_send_t 结构体(用于发送)以及相关的函数给开发人员提供了非阻塞的 UDP 服务. 所以, 真正读写 UDP 的函数与普通的流式读写非常相似.为了示范如何使用 UDP, 下面提供了一个简单的例子用来从 DHCP 获取 IP 地址. – DHCP 发现.

Note

你应该以 root 用户运行 udp-dhcp, 因为该程序使用了端口号低于 1024 的端口.

uv_loop_t *loop;
uv_udp_t send_socket;
uv_udp_t recv_socket; int main() {
    loop = uv_default_loop();

    uv_udp_init(loop, &recv_socket); struct sockaddr_in recv_addr = uv_ip4_addr("0.0.0.0", 68);
    uv_udp_bind(&recv_socket, recv_addr, 0);
    uv_udp_recv_start(&recv_socket, alloc_buffer, on_read);

    uv_udp_init(loop, &send_socket);
    uv_udp_bind(&send_socket, uv_ip4_addr("0.0.0.0", 0), 0);
    uv_udp_set_broadcast(&send_socket, 1);

    uv_udp_send_t send_req;
    uv_buf_t discover_msg = make_discover_msg(&send_req); struct sockaddr_in send_addr = uv_ip4_addr("255.255.255.255", 67);
    uv_udp_send(&send_req, &send_socket, &discover_msg, 1, send_addr, on_send); return uv_run(loop, UV_RUN_DEFAULT);
}

0.0.0.0 地址可以绑定本机所有网口. 255.255.255.255 是广播地址, 意味着网络包可以发送给子网中所有网口, 端口 0 说明操作系统可以任意指定端口进行绑定.

首先我们在 68 号端口上设置了绑定本机所有网口的接收套接字(DHCP 客户端), 并且设置了读监视器. 然后我们利用相同的方法设置了一个用于发送消息的套接字. 并使用 uv_udp_send 在 67 号端口上(DHCP 服务器)发送 广播消息.

设置广播标志也是 必要 的, 不然你会得到 EACCES 错误 [1]. 发送的具体消息与本书无关, 如果你对此感兴趣, 可以参考源码. 若出错, 则读写回调函数会收到 -1 状态码.

由于 UDP 套接字并不和特定的对等方保持连接, 所以 read 回调函数中将会收到用于标识发送者的额外信息. 如果缓冲区是由你自己的分配的, 并且不够容纳接收的数据, 则``flags`` 标志位可能是 UV_UDP_PARTIAL. 在这种情况下, 操作系统会丢弃不能容纳的数据. (这也是 UDP 为你提供的特性).

void on_read(uv_udp_t *req, ssize_t nread, uv_buf_t buf, struct sockaddr *addr, unsigned flags) { if (nread == -1) {
        fprintf(stderr, "Read error %s\n", uv_err_name(uv_last_error(loop)));
        uv_close((uv_handle_t*) req, NULL);
        free(buf.base); return;
    } char sender[17] = { 0 };
    uv_ip4_name((struct sockaddr_in*) addr, sender, 16);
    fprintf(stderr, "Recv from %s\n", sender); // ... DHCP specific code  free(buf.base);
    uv_udp_recv_stop(req);
}

UDP 选项(UDP Options)

生存时间TTL(Time-to-live)

可以通过 uv_udp_set_ttl 来设置网络数据包的生存时间(TTL).

仅使用 IPv6 协议

IPv6 套接字可以同时在 IPv4 和 IPv6 协议下进行通信. 如果你只想使用 IPv6 套接字, 在调用 uv_udp_bind6 [2] 时请传递 UV_UDP_IPV6ONLY 参数.

多播(Multicast)

套接字可以使用如下函数订阅(取消订阅)一个多播组:

UV_EXTERN int uv_udp_set_membership(uv_udp_t* handle, const char* multicast_addr, const char* interface_addr,
    uv_membership membership);

membership 取值可以是 UV_JOIN_GROUP 或 UV_LEAVE_GROUP.

多播包的本地回路是默认开启的 [3], 可以使用 uv_udp_set_multicast_loop 来开启/关闭该特性.

多播包的生存时间可以使用 uv_udp_set_multicast_ttl 来设置.

DNS 查询(Querying DNS)

libuv 提供了异步解析 DNS 的功能, 用于替代 getaddrinfo [4]. 在回调函数中, 你可以在获得的 IP 地址上执行普通的套接字操作. 让我们通过一个简单的 DNS 解析的例子来看看怎么连接 Freenode 吧:

int main() {
    loop = uv_default_loop(); struct addrinfo hints;
    hints.ai_family = PF_INET;
    hints.ai_socktype = SOCK_STREAM;
    hints.ai_protocol = IPPROTO_TCP;
    hints.ai_flags = 0;

    uv_getaddrinfo_t resolver;
    fprintf(stderr, "irc.freenode.net is... "); int r = uv_getaddrinfo(loop, &resolver, on_resolved, "irc.freenode.net", "6667", &hints); if (r) {
        fprintf(stderr, "getaddrinfo call error %s\n", uv_err_name(uv_last_error(loop))); return 1;
    } return uv_run(loop, UV_RUN_DEFAULT);
}

如果 uv_getaddrinfo 返回非零, 表示在建立连接时出错, 你设置的回调函数不会被调用, 所有的参数将会在 uv_getaddrinfo 返回后被立即释放. 有关 hostname, servname 和 hints 结构体的文档可以在 getaddrinfo 帮助页面中找到.

在解析回调函数中, 你可以在 struct addrinfo(s) 结构的链表中任取一个 IP. 这个例子也演示了如何使用 uv_tcp_connect. 你在回调函数中有必要调用 uv_freeaddrinfo.

void on_resolved(uv_getaddrinfo_t *resolver, int status, struct addrinfo *res) { if (status == -1) {
        fprintf(stderr, "getaddrinfo callback error %s\n", uv_err_name(uv_last_error(loop))); return;
    } char addr[17] = {'\0'};
    uv_ip4_name((struct sockaddr_in*) res->ai_addr, addr, 16);
    fprintf(stderr, "%s\n", addr);

    uv_connect_t *connect_req = (uv_connect_t*) malloc(sizeof(uv_connect_t));
    uv_tcp_t *socket = (uv_tcp_t*) malloc(sizeof(uv_tcp_t));
    uv_tcp_init(loop, socket);

    connect_req->data = (void*) socket;
    uv_tcp_connect(connect_req, socket, *(struct sockaddr_in*) res->ai_addr, on_connect);

    uv_freeaddrinfo(res);
}

网络接口(Network interfaces)

系统网络接口信息可以通过调用 uv_interface_addresses 来获得, 下面的示例程序将打印出机器上所有网络接口的细节信息, 因此你可以获知网口的哪些域的信息是可以得到的, 这在你的程序启动时绑定 IP 很方便.

#include  #include  int main() { char buf[512];
    uv_interface_address_t *info; int count, i;

    uv_interface_addresses(&info, &count);
    i = count;

    printf("Number of interfaces: %d\n", count); while (i--) {
        uv_interface_address_t interface = info[i];

        printf("Name: %s\n", interface.name);
        printf("Internal? %s\n", interface.is_internal ? "Yes" : "No"); if (interface.address.address4.sin_family == AF_INET) {
            uv_ip4_name(&interface.address.address4, buf, sizeof(buf));
            printf("IPv4 address: %s\n", buf);
        } else if (interface.address.address4.sin_family == AF_INET6) {
            uv_ip6_name(&interface.address.address6, buf, sizeof(buf));
            printf("IPv6 address: %s\n", buf);
        }

        printf("\n");
    }

    uv_free_interface_addresses(info, count); return 0;
}

is_internal 对于回环接口来说为 true. 请注意如果物理网口使用了多个 IPv4/IPv6 地址, 那么它的名称将会被多次报告, 因为每个地址都会报告一次.