@Chingim
1.你理解成我是倚老卖老也算是一种新的思路.我的本意是说你幼稚.
2.首先不是什么语言都有框架让你去认 content-type 的.裸解析 tcp 了解一下(我至少用两种语言做过这种事,因为它没有成熟的框架).其次,我已经说了假设了,假如一个 c 系程序员野蛮的把两个 json 拼接到一个 body 里.content-type 设成 text.现在要分别解析出两个 json 对象,那么这个最外层的引号就成为了一种分界标志.所以 string(string)+string(string)之后是一个 string,但是可以反解析出两个子 string.但是单纯的 string+string 是会完全合并成一个 string,不可逆的.
3.我再次强调这只是理论上的价值,有无数的理由让我们不要这样做.
4.你显然没有理解我上个回复中强调的内容.不要混淆 json 本身是个 string,即纯文本的本质.

@Chingim 应该是被成熟框架养得娇嫩的程序员吧.笑~.考虑一种情况.body 中不只是 json 或者不止一个 json 呢?
这么和你讲好了.我们可以把数据大概的看成三个层次:
1.最底层.一切皆是二进制.
2.中间层,数据都是 int/double/string/bool 等.
3.最上层,数据是 json/http/h264/mp3.
永远是越下层越通用.所以把 json 重新包装成 string,是把它通用化了.
当然,有一个概念不要混淆,json 以 string 作载体.这是协议规定的.也就是说,序列化后的 json 肯定是一个 string 即字符串.这个时候再做一次包装是 string(string).
做这个操作其实是很丑陋的.完全不建议这样用.
(可以用更好的办法规避它.比如永远保证一个 body 即是一个 json,json 里放 json 就可以了) 然而这就不在我们的讨论范围了.

我倒觉得还是有讨论价值的.
如果当成 json 对象,那么报文如下:
HTTP head
{"dds":2}
如果当成字符串,那么报文如下:
HTTP head
"{\"dds\":2}"
如果通信是使用成熟的框架肯定是第一种直接,Body 即 json.
但是如果考虑到通用性,其实第二种也有存在的价值.原因在于它被首先认为是一个字符串,这样即使在不支持 json 解析的系统中也被看成是一个整体.

@wohenyingyu03 感谢回复,不过你说的只是 kcp 本身的原理和理想情况下使用 kcp 所带来的开销.(kcp 本身并不是针对 fq 开发的(为了游戏),kcptun 倒是可以说是为了 fq 而生)
并且,你说的这些和大量重复发包并不冲突.我说的是表象,你讲的是重复发包的原因.kcptun 是基于 udp 的 kcp 实现,当你在 kcptun 中设置较高的流畅度时,在 fq 的场景下,流量 double 是很正常的.你可以实测一下.
同时倒推一下现象也不难发现,突然不能使用 kcptun 了,但同时在 kcptun 的 server 和 client 都不修改任何参数的情况下,隔一段时间又突然能上了.这不就是明显的被临时 block 端口的表现吗?那能被临时 block 端口的原因无外乎这么几个了.

kcptun 是通过大量的重复发 UDP 包来实现加速.而这种加速其实挺占带宽的.甚至看起来像是 DDOS,所以很容易被链路上的某点封端口或者临时黑名单.

另外补充一下,楼主图中的三种粘包情况的示意图,显然是一个半吊子人画的,1 和 2 还能理解是站在应用层看待 tcp 传输的,而情况 3 是不可能在应用层发生的.
情况 3 的确是 tcp 传输过程中会遇到的,但如果要讨论,这情况就多了去了:丢包,重包,乱序包.tcp 本身都已经把这些都处理掉了,所以在应用层,要么能接收到正确的数据,要么就是读不到数据.不会有情况 3 出现的.

楼主不要被楼上阵容整齐的的嘲讽给吓到了.其实很多人都吃过这个亏的.
楼主能够一本正经的整理出这么一大堆资料,也是一个认真的人.
相信你能在别的事情上成功的.
解释一下粘包,TCP 确实是没有粘包这个说法.之所以会有这个错觉产生,其实是由于自我脑补.
很多人第一次入门网络编程,往往是发一个"helloworld"到另一端,对端大多数时候一次回调或者读取就收到了整个的"helloworld".自然地就以为发了一次,收了一次.就是一个数据包的传输完成了.
这中间发生了什么呢?TCP 底层收到命令到要发送一块内存数据("helloworld"),那么发送端就一个一个字节(只是比喻,实际是 IP 数据帧)地向接收端发送.接收端也开始一个字节一个字节的接受.在发送前,两端没有任何的通信来约定这一次传输一共有多少长的数据.也就是说接收端在收到第一个字节的时候,并不知道接下来它还会收到剩余多少数据.
那么问题就来了,接收端通知你有数据可读时,是以什么为依据呢?
它的逻辑概括一下是(好久好久前的东西了,并不准确):1.收到了一些数据,并且在随后若干毫秒内就没有新数据了;2.数据缓存区满了;3.收到了其它的指令(重置,断开等).以上任意条件触发,那么就通知上层(你的程序)有 TCP 数据到来了.但是它本身并没有你所以为的另外一层含义----这是一个完整的数据包的到来.
只要清楚 TCP 的这一本质,那么你在写代码时就要知道,当你被通知有数据可以接收时,此刻能读取的这些数据本身并没有任何意义,它可能是某个完整数据包的一部分,也可能就是一个完整的数据包.只有你自己亲自去拆开(解析)它后才能判断.

只要是解码后再做操作的都是达不到 60 倍的.所以什么重采样之类的肯定是不行的.
所以核心思路是在解码前就决定出要显示多少帧画面,然后只解码这些帧,顺序播放出来.
如果是 H264 的话,提取出所有的 I 帧,基本上 I 帧都是完整压缩,而且是隔至少 1 秒才一张.
真正要做的就是挑出所有的 I 帧,然后根据快进倍速跳着解码渲染即可.

@Mmmmc 你的需求真的适合之前提到的第二种方式.建议了解一下.笑~
再回到问题:
1.从你的描述来看,你对编程的理解确实是萌 99 新.所以我已经无从下手去回答你的问题了.
话虽这么说,还是回答一下,readIRTInfo()的确是放到 run 里.然后 Model 和 View 之间用信号槽通信.实现时注意遵循 QT 推荐的 MV 模式.

2.变量,说得大一点.这里有一个是面向对象还是面向过程的区别.如果是面向对象的话,是放到类的成员变量里.对应的,类的生存周期就是跟着设备走的.有一个设备就有一个类.设备完成测试就销毁掉类.如果是面向过程的话,是放到 run 里,对应的类的生存周期是跟着程序走,也就是说 10 个线程类一开始就开在那,有一个设备来了,就通知到 run 里,run 里临时声明一组变量(实现上就是一个设备信息的 struct),跑完后就 hold 在那,等着下一个设备到来,memset 一下针对新的设备开始跑.


总结就是放哪都可以.但这是一个思维模式上的区别.不过看你已经给出的这些信息,你的思考是偏向过程的.可能是 C 看的比较多一点.所以我让你了解的第二种方式,还是先不用看了.笑~(还不到看的时候,以后还有的是时间)

难得 V2 上有 QT 的问题,尽自己的能力回答一下.不一定都对.

结合你的需求,建议用楼上说的第二种形式.代码上看起来麻烦一点.逻辑也有点绕,不过最适合你的情况.
当然,你用的就是第一种形式.所以针对你这种形式产生的问题,以下回答:
逻辑代码当然是放进 run()里,不然多线程的意义在哪.
用继承的方式实现线程,有一点要特别注意,你的子类 Thread 除了 run()里的代码是跑在新线程里.其它的信号槽都是在父线程里的.这个逻辑上的区别不知道怎么解释给萌新听,结果就是很多时候程序没有按照你想的方式运行.
引用官方对这继承方式的警告:It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread that calls run(). This means that all of QThread's queued slots will execute in the old thread. Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread.

变量问题,不懂你的疑问点在哪.如果这些变量是专属于某个硬件的,那么放进这个类里.如果是十几个硬件共享的数据,那么放进一个全局单例中共享访问.记得加锁.

@Gimini 现在可以提 issues 给我哦.

@harry890829 开源了哦.

有地址吗,有机会可以做一点贡献!

顶一下.竟然有原生的 api,果然我微软大法好.
ps:我也做了个答题的辅助工具,高峰期 baidu 会过 5.6s 才返回结果,很不满意.这样一下 Ocr 的效率可以提高到极限啦.

@silencefent 哈?现在还有人在用 32 位的系统吗...大意了啊.

@xiqingongzi 能量球的好处在于程序"总在最前",这样可以在工作中无缝识别.丑...不是现在要考虑的问题啦.哈哈...你说的拖到图标上我也会做的.

@ORZRRR 没有哦.无论哪一家,都有 N 种接口开放出来.针对不同场景有不同的接口.比如身份证,车牌,驾照等.我用的也只是百度的通用图片识别接口,也就意味着针对身份证,驾照这种特殊场景是没有优化过的.我用百度仅仅是先搜了他家的资料.就直接用了...
哈哈貌似有点随意啥.我倒是想比较 google 的,但是要我输信用卡啊啥的,懒得弄了.

@xiqingongzi
嗯.拖文件到图标上来这个,我觉得不如做个类似 360 的能量球的东西.不用时吸在屏幕边上,用的时候直接把图片拖到球上.不过这个就跟现在的也差不多了.只不过现在是一张图片.
anyway,我会试试看的.