TCP通信程序练习4

声明

文章仅用作个人学习，部分内容为参考他人文章，参考文章原文链接：https://blog.csdn.net/qq_46331050/article/details/117706050

4. 上传文件，并得到服务器的反馈

客户端：数据来自于文本文件，接收服务器反馈
服务器：接收到的数据写入文本文件，给出反馈

1. 初次错误代码

客户端

服务器端

发现问题

如上两张图所示，程序一直运行不结束，这是为什么呢？

因为通俗来讲：两边都在等待对面先结束，也就是服务器端不确定客户端是否还要继续发送数据，而客户端也不确定服务器端是否还能继续接受数据，这就导致了两边都在"等"。

那么该如何解决这种问题呢？

解决方案

方案一：自定义结束标记（不推荐）

客户端在发送完毕文件中的数据以后，再写一个886作为结束标志

服务器端如果接受到这个886，就"知道了"发送已经结束，退出while循环

方案二：禁用发送方套接字的输出流（推荐）

当客户端文件数据发送完毕以后，禁用客户端套接字输出流，客户端输出流一断，服务器端就"明白"客户端出于某种原因要结束数据传送了，服务器端也停止工作

客户端程序

方案三：暴力方法（相当不推荐）

我直接手动关闭程序不就行了，反正数据已经传送完毕了，我管你两边知不知道要不要继续传输呢，我把线一拔，你俩想不结束也不行。如下图所示，文件已经传输完毕

但是很明显，我要的结果是客户端要收到反馈！！！上边这些方法指定是不行的

2. 二次错误代码

客户端

服务器端

发现问题

如图所示，程序是可以自动结束了，但是又报异常了

这是为什么呢？

注意，服务器端接收数据完毕以后是要给客户端发送一个反馈的，这就形成了一个输出流

但是我并没有在服务器端的反馈消息发送完毕以后关闭服务器端套接字的输出流，又形成了初次错误代码的那个问题......

加上套接字输出流关闭方法，异常成功消失，又出问题了！

3. 三次错误发现

服务器反馈为null？不应该是反馈为提前设定好的"文件上传成功"吗？

说明服务器端的反馈信息并没有被客户端成功接收

解决

原来是这里出现了错误，应该是bwServer.flush();

4. 最终程序

客户端

服务器端

至此，该练习成功完成。

但第三次的错误引发了我的思考：用缓冲流传输数据以后，为什么要清空缓冲区？

清空缓冲区，为什么？

声明

此部分内容引用于csdn用户：呼卓宇

原文链接：https://blog.csdn.net/lsx991947534/article/details/45065773

首先先看一段代码：

out.flush();
out.close();

这在我以前的代码里有所体现，但是只知道这是清空缓冲区的作用，但是不知道具体什么是缓冲区，以及为什么要清空他，所以今天学习了一下，我简单举个例子你们就知道了：

首先，咱们设想要给鱼缸换水，所以需要一个水泵，水泵是连接鱼缸和下水道的，咱们的任务就是将鱼缸里面水全抽干，这时，我们就可以把水管当做缓冲区。如果咱们一见鱼缸里面水抽干了就立马关了水泵，这时会发现水管里还有来不及通过水泵流向下水道的残留水，我们可以把抽水当做读数据，排水当做写数据，水管当做缓冲区，这样就容易明白了。

那么这样一来我们如果中途调用close()方法，输出区也还是有数据的，就像水缸里有水，只是在缓冲区遗留了一部分，这时如果我们先调用flush()方法，就会强制把数据输出，缓存区就清空了，最后再关闭读写流调用close()就完成了。

缓冲区可以简单地理解为一段内存区域。可以简单地把缓冲区理解为一段特殊的内存。某些情况下，如果一个程序频繁地操作一个资源（如文件或数据库），则性能会很低，此时为了提升性能，就可以将一部分数据暂时读入到内存的一块区域之中，以后直接从此区域中读取数据即可，因为读取内存速度会比较快，这样可以提升程序的性能。

5. 总结

需要注意的是：socket相关的流的读是阻塞的，也就是说。A关闭输入流之前，要考虑B端的输出流是否还要继续写。否则，B端一直等待A端接收而A端却接受不了，B一直阻塞。同样，A端将输出流关闭了，B端却一直在读，却读不到内容，一直阻塞。上述两种情况会跳出一大堆异常。
用缓冲流发送数据一定要记得最后清空缓冲区
遇到问题多思考，以后才能少写点bug