本文共 1608 字，大约阅读时间需要 5 分钟。

前言

用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安装时，已经检测到了这些组件的设置。

转载地址：https://lostspeed.blog.csdn.net/article/details/100808647 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！