最近看了一些有关 libuv 的东西,另外复习了一些与同步、异步、阻塞、非阻塞,异步IO(aio)的东西, 算是技术积累吧,等有时间了整理出一个完整的文档出来,希望在今后的编程中用到。

不多说了,本文是今后几篇《libuv 中文编程指南》的前言,先介绍下 libuv 究竟是干什么的吧,看看 ​​ 开源中国社区收录的有关 libuv 的介绍​​,

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 中文编程指南(二)libuv 基础​​​


libuv 中文编程指南(三)文件系统

libuv 中文编程指南(四)网络

另外四篇我会在完成翻译后一起更新,如果你也想一起翻译文档,可以 fork 仓库 ​​ https://github.com/forhappy/uvbook​​,共同完善这份文档 ;-)


序言

本书由一系列 ​​ 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/


文件系统

简单的文件读写是通过 uv_fs_* 函数族和与之相关的uv_fs_t



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



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

同步 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()



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

此处给你展示了编写异步程序的通用模式, 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



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 套接字, 文件, 管道, 和进程间通信都可以作为流



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

为了示范流的用法, 我们借助了(管道) uv_pipe_t , 这使得我们把本地文件变成了流[#]_. 下面是利用 libuv 实现的一个简单的tee

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



./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

在任何情况下出错, read 回调函数 nread 参数都为 -1. 出错原因可能是 EOF(遇到文件尾), 在此种情况下我们使用 ‘’uv_close()’’ 函数关闭所有的流,uv_close() 会根据所传递进来句柄的内部类型来自动处理. 如果没有出现错误,nread 是一个非负数, 意味着我们可以向输出流中写入nread



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 <command> <file1> [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

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


  1. uv_fs_event_t*handle - 监视器. filename 字段是该监视器需要监视的文件.
  2. constchar *filename - 如果监视目录, 则该参数指明该目录中发生了变更的文件, 在 Linux 和 Windows 平台上可以是非 null.
  3. int flags - UV_RENAME 或UV_CHANGE.
  4. int status


我们的例子只是简单地打印出参数, 并通过 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
  2. uv_tcp_bind
  3. 在指定的监视器上调用 uv_listen
  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

当客户端发起了新的连接时, 回调函数需要为客户端套接字设置一个监视器, 并调用 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



仅使用 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




#include <stdio.h>
#include <uv.h>

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