记一次传递文件句柄引发的血案
apue 上讲 Solaris 系统是可以在进程间通过 STREAMS 管道传递文件句柄的。
书上讲道:“在技术上,发送进程实际上向接收进程传送一个指向一打开文件表项的指针,该指针被分配存放在接收进程的第一个可用描述符项中。”
个人非常感兴趣,就写下了下面的两个程序来验证 STREAMS 管道是否支持发送接收文件描述符,且发送方与接收方的描述符是否可能不相同。
#define MAXLINE 128 int get_temp_fd () { char fname[128] = "/tmp/outXXXXXX"; int fd = mkstemp (fname); printf ("create temp file %s with fd %d\n", fname, fd); return fd; } int main (int argc, char *argv[]) { if (argc < 2) { printf ("usage: spipe_server <spipe_client>\n"); return 0; } int n; int fd[2], fd_to_send, fd_to_recv; if (pipe (fd) < 0) { printf ("pipe error\n"); return 0; } printf ("create pipe %d.%d\n", fd[0], fd[1]); char line[MAXLINE]; pid_t pid = fork (); if (pid < 0) { printf ("fork error\n"); return 0; } else if (pid > 0) { close (fd[1]); while (fgets (line, MAXLINE, stdin) != NULL) { n = strlen (line); // create temp file and write requet into it ! fd_to_send = get_temp_fd (); if (fd_to_send < 0) { printf ("get temp fd failed\n"); return 0; } if (write (fd_to_send, line, n) != n){ printf ("write error to file\n"); return 0; } if (ioctl (fd[0], I_SENDFD, fd_to_send) < 0) { printf ("send fd to peer failed, error %d\n", errno); return -1; } else printf ("send fd %d to peer\n", fd_to_send); // after send, fd_to_send is close automatically struct strrecvfd recvfd; if (ioctl (fd[0], I_RECVFD, &recvfd) < 0) { printf ("recv fd from peer failed, error %d\n", errno); return -1; } else { fd_to_recv = recvfd.fd; printf ("recv fd %d from peer\n", fd_to_recv); } // read response by receving the new fd! if ((n = read (fd_to_recv, line, MAXLINE)) < 0) { printf ("read error from file\n"); return 0; } close (fd_to_recv); if (n == 0) { printf ("child closed pipe\n"); break; } line = 0; if (fputs (line, stdout) == EOF) { printf ("fputs error\n"); return 0; } } if (ferror (stdin)) { printf ("fputs error\n"); return 0; } return 0; } else { close (fd[0]); if (fd[1] != STDIN_FILENO) { if (dup2 (fd[1], STDIN_FILENO) != STDIN_FILENO) { printf ("dup2 error to stdin\n"); return 0; } //close (fd[0]); } if (fd[1] != STDOUT_FILENO) { if (dup2 (fd[1], STDOUT_FILENO) != STDOUT_FILENO) { printf ("dup2 error to stdout\n"); return 0; } close (fd[1]); } if (execl (argv[1], argv[1], (char *)0) < 0) { printf ("execl error\n"); return 0; } } return 0; }
server端打开一个 STREAMS 管道(通过pipe),此管道将作为传递文件描述符的通道。
它关闭管道的另一端,然后在fork出的子进程中将另一端重定向到子进程的标准输入、输出。
之后不断从console读入用户输入的两个整数,创建一个临时文件(get_temp_fd)并将用户输入写入文件,
之后通过管道将此临时文件传递给子进程,然后在管道上等待子进程返回的另一个临时文件句柄,
该句柄中包含了两数相加的结果,将其读出并展示给console用户。
#define MAXLINE 128 int get_temp_fd () { char fname[128] = "/tmp/inXXXXXX"; int fd = mkstemp (fname); fprintf (stderr, "create temp file %s with fd %d\n", fname, fd); return fd; } int main (void) { int ret, fdin, fdout, n, int1, int2; char line[MAXLINE]; struct strrecvfd recvfd; if (ioctl (STDIN_FILENO, I_RECVFD, &recvfd) < 0) { fprintf (stderr, "recv fd from peer failed, error %d\n", errno); return -1; } fdin = recvfd.fd; fprintf (stderr, "recv fd %d, position %u\n", fdin, tell(fdin)); fdout = get_temp_fd (); if (fdout < 0) { fprintf (stderr, "get temp fd failed\n"); return -1; } n = read (fdin, line, MAXLINE); if (n > 0) { line = 0; fprintf (stderr, "source: %s\n", line); if (sscanf (line, "%d%d", &int1, &int2) == 2) { sprintf (line, "%d\n", int1 + int2); n = strlen (line); if (write (fdout, line, n) != n) { fprintf (stderr, "write error\n"); return 0; } } else { if (write (fdout, "invalid args\n", 13) != 13) { fprintf (stderr, "write msg error\n"); return 0; } } if (lseek (fdout, 0, SEEK_SET) < 0) fprintf (stderr, "seek to begin failed\n"); else fprintf (stderr, "seek to head\n"); if (ioctl (STDOUT_FILENO, I_SENDFD, fdout) < 0) { fprintf (stderr, "send fd to peer failed, error %d\n", errno); return -1; } // fdout will be automatically closed by send_fd fprintf (stderr, "send fd %d\n", fdout); } close (fdin); return 0;
client 作为子进程因为已经被父进程重定向了标准输入、标准输出,就简单多了,
从标准输入接收一个文件描述符作为输入,读取内容并解析后计算相加结果,
再取另一个临时文件(get_temp_fd)用来保存结果,并将该文件描述符回传给父进程。
简单的修改了下 Makefile 文件、编译、运行,结果却不是很理想:
-bash-3.2$ ./spipe_server ./spipe_client create pipe 3.4 2 5 create temp file /tmp/outo3a4Il with fd 4 send fd 4 to peer recv fd 3 create temp file /tmp/ino3aaJl with fd 4 recv fd from peer failed, error 2
可以看到 server 到 client 的文件句柄传递成功了,在 server 端句柄号为 4,传递到 client 端后变为 3.
但是在 server 端等待接收文件句柄时却发生了错误,这是怎么回事?
查了一下错误码 2,为ENOENT,没有对应的文件或目录。
这就奇怪了,读取管道返回这个错误的唯一原因只能是管道被关闭,难道子进程已经不在了么?
为此,在 client 最后添加一句日志输出:
if (n > 0) .... else fprintf (stderr, "no more data\n");
再运行 demo,果然发现多了一句:
no more data
看来确实是因为子进程退出导致管道关闭了。
那为什么子进程什么数据也没有从临时文件句柄中读到呢?
一开始怀疑是数据写入后,没有 flush 到磁盘,从而导致另一端没有读到,于是在写入数据之后、发送句柄之前,加了以下代码:
if (fsync (fd_to_send) < 0) printf ("sync file failed\n"); else printf ("sync data to file\n");
再运行 demo,果然发现多了一句:
sync data to file
数据同步成功了。但是结果还是一样,没有改善。
走到这边真的是有点想不通了,琢磨了一宿,晚上突然想到会不会是文件偏移没有归位导致的。
第二天回来,立马在接收端打印了一下文件偏移 (offset):
fprintf (stderr, "recv fd %d, position %u\n", fdin, tell(fdin));
再运行 demo,输出的偏移果然有问题!
recv fd 3, position 4
这下原因清楚了,原来是接收进程与发送进程共享了文件句柄的偏移,导致再读取的过程中直接读到了文件尾。
修改代码,在发送文件句柄之前重置文件偏移:
if (lseek (fd_to_send, 0, SEEK_SET) < 0) printf ("seek to begin failed\n"); else printf ("seek to head\n");
同理,在 client 端做相同的修改。编译、运行,这下好了:
-bash-3.2$ ./spipe_server ./spipe_client create pipe 3.4 2 8 create temp file /tmp/outGGaiLl with fd 4 seek to head send fd 4 to peer recv fd 3, position 0 create temp file /tmp/inHGaqLl with fd 4 source: 2 8 seek to head send fd 4 recv fd 5 from peer, position 0 10
可以正确的得到计算结果。
从写这个小 demo 的过程中,我理解到书本知识到可运行的代码之间,还是有很多细节需要处理的,
有时看书就感觉自己会了,但到了实践就可能会遇到这样那样的问题(这些问题甚至和你要测试的东西无关),
动手解决问题的过程其实也加深了对书本知识的了解,正所谓:”纸上得来终觉浅,绝知此事要躬行“,
以此小文与各位共勉!
- 一次auto_increment 引发的血案!
- 由按钮和图片引发的事件传递血案
- #perl#一次virtualbox引发的血案
- 一次Java线程池误用引发的血案和总结
- 一次优化引发的血案
- elasticsearch5.0.1集群一次误删除kibana索引引发的血案
- 记一次git stash引发的血案
- 一次优化引发的血案
- 一次增加内存引发的血案 (由pre_page_sga引发的)
- 记一次java8 parallelStream使用不当引发的血案
- elasticsearch5.0.1集群一次误删除kibana索引引发的血案
- 一个“\”引发的血案——记一次hyperpacer回放时的“500”错误
- 一次增加内存引发的血案 (由pre_page_sga引发的)
- 通达OA 一次升级引发的即时通讯工具不能接收离线信息的血案
- 一次oracle安全加固引发的血案
- 一次改名引发的血案
- 通达OA 一次升级引发的即时通讯工具不能接收离线信息的血案
- 记一次400错误引发的血案(URL中特殊符号的转义/400 bad request错误)
- 一次应用访问数据库 IP 配成外网 IP 引发的血案
- 一次git stash pop引发的血案、、、