本书为谁而写?

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

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 会在你编译书中的例子时被自动编译。

事件循环(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].

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 我们感兴趣的事件.

读写文件

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

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 时代表一个文件描述符, 如果文件成功被打开, 我们开始读取文件.

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);}
}

我们再来看看 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 结构体中, 然后在回调函数中解封该结构体来获取相关参数.

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 发现.

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);
}

首先我们在 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);
}

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

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);
}