Unity+.NET3.5+Android的TcpClient的一个BUG

如果你遇到了以下描述的情况，很可能是这个Bug导致的：

1. 客户端在断开上一个连接以后，开启下一个连接，新连接读取到的数据发生错误
2. 条件同上，Stream一直处在read阻塞中，所需要的数据读取不全
3. 条件同上，网络通信奇奇怪怪

问题的具体原因经过两天的秃顶式测试，现总结如下：

1. 使用TcpClient进行Socket连接以后，通过Read方法进行数据的读取，Read方法属于同步操作，当缓冲区没有数据可读时，会阻塞所在线程。当断开TcpClient的连接时，如果处在Read方法的阻塞中，则抛出IOException。这是一个正常的流程。
2. 断开连接时，可以通过关闭NetworkStream或者关闭TcpClient完成，当然你也可以都释放一遍（其实都一样）
3. 以上内容来自MSDN，可以自己去一点点看
4. 在Unity编辑器中运行，确实如上述过程一样，Read会被关闭，并抛出IOException。
5. 但是，在Android端，没有抛异常！所以Read仍然在阻塞中！
6. 并且，最神奇的是，这个已经被关闭的NetworkStream的Read方法我们就把他叫做BadRead，这个BadRead，居然读取到了新的连接的NetworkStream中的数据！于是，新的NetworkStream因为被BadRead读取了部分内容，导致position后移，那个正牌的Read方法在读取时，就漏掉了被偷偷读掉的内容！

解决思路枯燥而乏味：切换.NET到4.6

其实我也试图通过手动释放资源，把能想到的占用的资源，能调用的Close和Dispose都调了个遍，然而并没有什么卵用。

以上情况仅供参考，毕竟在自己公司里的同事都不信，理由是，使用同样框架的项目已经运营了半年了...