ST源码分析-proxy - 弦外之音

本文主要讲解，ST 提供的示例程序 proxy ，make 编译之后，会在 obj 目录生成 proxy 可执行文件，如下：

proxy 是一个流量代理程序，可以把TCP流量转发给远程服务器，使用命令如下：

用 -X 是只开启一个进程，简单起见，先讲解单进程的逻辑。

./obj/proxy -X -l 192.168.0.122:8999 -r 124.223.94.246:80

上面的命令，会把所有访问 192.168.0.122 机器的 8999 端口的TCP流量，全部转发给 124.223.94.246:80。

接下来，用 Clion 搭建好 proxy 的可视化调试环境，跟之前的 lookupdns 一样，可以看之前的文章《ST源码分析-Clion调试》

proxy 程序的单进程逻辑比较简单，流程图如下：

从上图可以看到，除了 idle 协程，其他所有协程做的事情都是对于在 系统线程 看来都是非阻塞，非阻塞协程干的话，就是把需要监听的 fd 放进去全局变量 fd_set，然后由 idle 协程执行 select() 函数阻塞，等待信号。ST的调度策略是 _ST_RUNQ 里面已经没有协程要运行了，才会切换到 idle 协程来阻塞。

proxy 程序的单进程逻辑看上面的流程图，跟自己看代码就能理解，比较简单。

下面开始讲解 proxy 的多进程模式。只需要把 -X 命令行参数去掉，就会执行 set_concurrency() 函数，如下图：

去掉 -X 参数之后， proxy 就会调用 start_daemon() 函数进入守护进程模式，clion 就不好调试了，只能用 gdb 。

相比于单进程模式，多进程只是多掉了两个函数。

1，start_daemon()，进入守护进程模式

2， set_concurrency() ，开启多进程处理请求。

所以重点分析一下 set_concurrency() 函数就足够了，代码如下图：

上图代码很简单，没有 watchdog 机制，只是 fork() 了好几个进程。下面就来讲解 fork 这么多进程之后，对后续的逻辑有什么影响。

fork 之后，后续的进程会把变量srv_nfd 都拷贝一份，但是 fd 本身是一个 int，只是一个底层描述符列表的索引，可以理解为指针，即使是多进程，系统 fd 底层还是用的同一个。也就是说多个进程的 idle 协程同时 select 监听这个 srv_nfd。

我们看一下这种情况，如果一个客户端来了，是不是所有进程的 select() 都会激活。在 select() 函数后面加入调试代码，如下：

/* Open and write */
    char file_name[80] = "/home/ubuntu/Documents/st-1.9/obj/pid_";
    char pid_name[20] = {0};
    sprintf(pid_name,"%d",(int)getpid());
    strcat(file_name,pid_name);
    int log_fd = open(file_name, O_CREAT | O_WRONLY | O_TRUNC, 0644);
    write(log_fd, file_name, strlen(file_name));
    close(log_fd);