前言
用QT4.7.0做的客户端和客户qt4版服务器通讯时，各种超时，包不全。
我的客户端为了简单，用的是同步通讯，发了一个包后，死等回包，如果超时了都没有收包信号，那就通讯失败。
客户的服务是异步处理的通讯，对1个socket有2个线程再处理，一个只管收包，一个只管发包。按理说，我发包后，等了那么长时间，怎么会不回包给我，或回包没收全…
客户给了一个他们的旧版服务端工程做参考，我准备砍掉多余代码，只保留通讯功能。看看通讯时，到底出了啥问题…
本来想在win版qt上砍的，发现参考工程各种操作用的都是linux的API.
准备砍个linux版的服务端，来验证通讯问题。
看了客户的服务端通讯部分了，明白为啥有时没回包。
他为了执行不卡顿，客户端发送命令干活时，服务端直接将客户端的命令保存起来。
然后，从缓存中，将一些事先备好的数据(先前用户命令的执行结果)，返给客户端。如果缓存中数据已经都送给了客户端或没有新的命令执行结果。这时，就不会给客户端回包…
而且回包还有点奇葩，有可能返回多个结果包给客户端，这确实不好理解，怎么协议整成这个样子。一问一答多好啊。
在这种通讯机制下，客户端就不能发了一个命令，然后死等回包。
而是发送命令后，就不管了。应该等QT socket有数据接收信号后，进数据接收函数中处理回包数据。
这种通讯机制，不是即时的，如果发了一个命令，在回包中如果没发现这种回包，还需要继续发送状态查询命令。如果发了半天状态查询，还没收到这种回包，那就需要继续发送控制命令，让服务端继续执行这种命令。
如果向服务端发送控制命令，执行的时间比较长，采取这种方式比较合理。
我觉得这种通讯方式，要改进的一点是：即使没有有效数据返回给客户端，也要回一个包，里面没有有效载荷就行。不至于让客户端死等。因为这时，网络是正常的。通讯机制，应该是一问一答的。
我win10本本上已经装了个vmware版的debian9, 刚安装完时，做了镜像。
就准备在这上边先装个QT4.7.0
实验
为了传东西，先装了scrt_sfx-x64.8.5.4.1942.exe，找了注册机。
装完之后，好用。SecureFX 8.5是传东西用的, SecureCRT 8.5是控制台。
为了拷贝虚拟机屏幕字符串，装了vmtools.
为了普通用户执行命令方便，将普通用户加入了sudoers.
更新了软件升级列表
sudo apt-get update
QT4.7.0的编译实验
QT4.7.0源码在debian9上编译不过，应该是gcc版本太高了，QT4.7.0的C语法在gcc下不合规。
QT4.8.7的编译实验
QT4.8.7源码在debian9上编译不过, 好像是QMAKE_CXXFLAGS的配置问题.
直接装debian9支持的QT4.8.7二进制安装包
折腾明白后，从虚拟机干净的镜像点开始安装。
// 下面这些是debian9自带的
sudo apt-get install build-essential
sudo apt-get install gdb
sudo apt-get install qt4-default
// 下面这个是从QT官网下载的
http://download.qt.io/official_releases/qtcreator/
qt-creator-opensource-linux-x86_64-4.10.0.run
将.run改权限 chmod 777
然后去debian9桌面的控制台进行安装. 安装路径改为/usr/local/qtcreator_4_10_0
安装完了，新建一个工程试一下。好使，可以编译，单步或直接运行。
不需要另外的设置(因为装qtcreator之前，先装了gcc, make, gdb等组件)，qtcreator安装时，已经检测到了这些组件的设置。
