mirror of
https://github.com/riba2534/TCP-IP-NetworkNote.git
synced 2026-05-07 22:12:54 +08:00
chore: 将所有外部图片本地化到仓库
- 下载 110 张外部图片到根目录 images/ 文件夹 - 更新所有 README.md 中的图片引用为统一路径 images/xxx.png - 55 张图片成功下载（PNG 格式） - 55 张失效图片创建占位文件（SVG/PNG） - 移除所有外部图片链接依赖 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
riba2534
@@ -52,7 +52,7 @@ gcc sep_serv.c -o serv
|
||||
|
||||
结果：
|
||||
|
||||
|
||||
|
||||
|
||||
从运行结果可以看出，服务端最终没有收到客户端发送的信息。那么这是什么原因呢？
|
||||
|
||||
@@ -64,15 +64,15 @@ gcc sep_serv.c -o serv
|
||||
|
||||
下面的图描述的是服务端代码中的两个FILE 指针、文件描述符和套接字中的关系。
|
||||
|
||||
|
||||
|
||||
|
||||
从图中可以看到，两个指针都是基于同一文件描述符创建的。因此，针对于任何一个 FILE 指针调用 fclose 函数都会关闭文件描述符，如图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
从图中看到，销毁套接字时再也无法进行数据交换。那如何进入可以进入但是无法输出的半关闭状态呢？如下图所示：
|
||||
|
||||
|
||||
|
||||
|
||||
只需要创建 FILE 指针前先复制文件描述符即可。复制后另外创建一个文件描述符，然后利用各自的文件描述符生成读模式的 FILE 指针和写模式的 FILE 指针。这就为半关闭创造好了环境，因为套接字和文件描述符具有如下关系：
|
||||
|
||||
@@ -80,7 +80,7 @@ gcc sep_serv.c -o serv
|
||||
|
||||
也就是说，针对写模式 FILE 指针调用 fclose 函数时，只能销毁与该 FILE 指针相关的文件描述符，无法销毁套接字，如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
那么调用 fclose 函数后还剩下 1 个文件描述符，因此没有销毁套接字。那此时的状态是否为半关闭状态？不是！只是准备好了进入半关闭状态，而不是已经进入了半关闭状态。仔细观察，还剩下一个文件描述符。而该文件描述符可以同时进行 I/O。因此，不但没有发送 EOF，而且仍然可以利用文件描述符进行输出。
|
||||
|
||||
@@ -88,7 +88,7 @@ gcc sep_serv.c -o serv
|
||||
|
||||
与调用 fork 函数不同，调用 fork 函数将复制整个进程，此处讨论的是同一进程内完成对文件描述符的复制。如图：
|
||||
|
||||
|
||||
|
||||
|
||||
复制完成后，两个文件描述符都可以访问文件，但是编号不同。
|
||||
|
||||
@@ -147,7 +147,7 @@ gcc dup.c -o dup
|
||||
|
||||
结果：
|
||||
|
||||
|
||||
|
||||
|
||||
#### 16.2.4 复制文件描述符后「流」的分离
|
||||
|
||||
@@ -159,7 +159,7 @@ gcc dup.c -o dup
|
||||
|
||||
这个代码可以与 [sep_clnt.c](https://github.com/riba2534/TCP-IP-NetworkNote/blob/master/ch16/sep_clnt.c) 配合起来使用，编译过程和上面一样，运行结果为：
|
||||
|
||||
|
||||
|
||||
|
||||
### 16.3 习题
|
||||
|
||||
|
||||
Reference in New Issue
Block a user