什么叫怪？这不是在向高手请教嘛？而且qq聊天有什么实时性要求嘛，收一个消息迟到了一两秒有什么关系，但是工业场合就很糟糕了。


【 在 clwd 的大作中提到: 】
: 是你的问题不要怪socket协议，qq都是用的socket协议
--
FROM 113.70.88.*

没，这几天没空搞这个问题。我用的是qt 4，也可能和qt库有关


【 在 poikilotherm 的大作中提到: 】
: 问题解决了吗？
--
FROM 113.70.64.*

你先看下协议里面有没有空读操作，如果有测试下时间，然后再下结论。


【 在 hengcuiyuan 的大作中提到: 】
: 请教开发过socket客户端的大佬，我弄了个socket客户端，和三菱的PLC做MC通信，实时性非常差，由于三菱的MC协议的报文结构没有报文的ID号，没法做异步通信，我用的是同步通信，很多时候要好几秒钟才能得到PLC的回复。写数据还好，读数据尤其慢，是不是操作系统哪里的设置问题？多线程的时候问题更严重。
--
FROM 111.19.113.*

用wireshark抓了一下包，发现通信的时间非常短，PLC的响应没有问题，但是数据包到了协议栈之后，有的时候触发qt的ReadyRead信号耗时很长，一般都有几十毫秒，偶尔出现几秒钟的情况，我每次通信的数据量很少，是不是数据量太少了，操作系统在等待更多的数据一起发送？有修改的方法吗？


【 在 foliver 的大作中提到: 】
: 先在链路上抓包，确定是哪端的问题。
: A端业务提交消息，链路传送消息，B端业务接收消息，B端提交回应消息，链路传送消息，A端业务收到回应。
: 把每个时间点记录下来，以便确定问题出现在哪里。
: ...................
--
FROM 113.70.67.*

我现在是多线程环境，通信程序在一个独立的线程里面，有点坑的是三菱的3E帧结构不含数据包的序列号的，所以我只能同步通信，我现在是只能一次通信完成之后再做下一次通信，信道被占用的时间里面就用QCoreApplication::processEvents去做事件处理。这种情况下，我发现：1、Debug模式下，数据包到了之后readyRead信号没有被触发，但release模式下，readyRead大部分情况被触发了；2、release模式下，偶尔出现数据包呆在协议栈里面几秒钟，readyRead不被触发，但是下一个数据包到来的时候，readyRead被立刻触发，导致粘包，无法处理；3、数据通信的时间很短，但是从协议栈到socket的时间要长的多。

可能是我的代码真写的有问题，我现在是需要读的时候读，需要写的时候写，每次数据传输的报文很小，再加上多线程环境，又没法搞异步通信，特别凌乱。我打算简单点，直接设定定时器来读和写，读完写，写完读，一次性把所有的数据读或者写完，也许可以解决这个问题。


【 在 z16166 的大作中提到: 】
: 大概率是qt的库没用对，贴你的代码让各位大拿看看
:
--
FROM 113.70.67.*