linux网络编程之socket编程(十)

今天继续socket编程的学习，最近晚上睡觉都没有发热，没有暖气的日子还是种煎熬,快乐的十一也已经走来，幸福有暖气的日子也快啦，好了，回到正题~

①close终止了数据传送的两个方向。

②shutdown可以有选择的终止某个方向的数据传送或者终止数据传送的两个方向。

但是，在实际应用中，可能会遇到这样一个情况，既使我们关闭了其中的某一端应用，但对于先前发送出去的数据能够得到对方的应答，下面可以用图来表示一下：

进一步说明一下"close终止了数据传送的两个方向"：

查看一下man帮助：

①、SHUT_RD=1代表不能向管道中读取数据了。

②、SHUT_WR代表不能向管道中写入数据了。

③、SHUT_RDWR代表不能向管道中读写数据了。

所以正好反映了，"shutdown可以有选择的终止某个方向的数据传送或者终止数据传送的两个方向"。

【说明】：

 

③shutdown how=1就可以保证对等方接收到一个EOF字符【也就是向对方发送了FIN TCP段】，而不管其他进程是否已经打开了套接字。而close不能保证，直到套接字引用计数减为0时才发送。也就是说直到所有的进程都关闭了套接字。

对于上面提到的，要想让client只终止写的一端，可以用shutdown设置成SHUT_WR，也就是how=1：

从上面的解释中来看："close不能保证，直到套接字引用计数减为0时才发送。也就是说直到所有的进程都关闭了套接字"，并不是只要调用了close就会立马向对方发送FIN tcp段，而是需要引用计数减为0时才发送，回想一下原来用fork()实现服务端的代码：

而如果改用shutdown:

说了一系列理论过后，下面用实验来进一步加深对shutdown的理解，也就是用shutdown来改写客户端。

目前我们的回射客户/服务端程序都已经改用select函数来实现了，下面我们来做一个这样的实验：

为了进行以上实验流程，需要改造一下实验环境，于是乎需小调整一下代码：

echocli.c:

echosrv.c:

下面来看下效果：

可见，并没回将数据回射回客户端，并且客户端这边报了一个错:

这是哪打印出来的呢？分析一下代码流程：

而且客户端的这个错误，还会导致服务端也崩溃掉了。

那如果这样处理是否可以避免这个报错呢？

编译运行：

可以看出，客户端并没有报错了，但是服务端还是崩溃了，这是为什么呢？

所以，解决服务端崩溃很简单，处理如下：

再次编译运行：

这时，可以看到服务端打印了"client close"，而且没有崩溃了，这是由于执行到了这个流程：

但是目前残留在管道当中的数据都无法回显给客户端，所以接下来用shutdown来进行改进，让它在客户端关闭的情况下还能回射回来：

编译如下：

从上面可以看到，客户端成功回显了，但是，发现有个小问题，就是当客户端回显数据之后，服务端没有把客户端给关闭掉，所以，程序应该有个bug，检查一下服务端的代码：

所以，修改如下：

编译运行：

这时问题就成功解决，此时的客户端就相对要完善一些了，实际上在编写TCP程序时是需要考虑到这一点的，实际上客户端程序还有一个地方是需要注意的：

所以可以加入一个flag进行处理：

当然程序运行效果是一样的，只是程序更严谨一些，好了，下次学习继续~