V2EX › xiao17174 的所有回复 › 第 2 页 / 共 4 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4

❮

❯

2020-01-17 11:21:29 +08:00

回复了 bibizhang 创建的主题 › 分享发现 › 我发现了一个“热水定律”

恰恰相反，我得出的热水定律是“当你想要一杯热水快速冷却时，这杯水真的会冷的更快！”
它的理论依据是：
1.很急喝水情况下，你会不停的用嘴去试探温度，小啜一口，这会不经意间提升你对热水的容忍程度，最后你可能在水温还是在 65 度左右就能完全喝下去了。（而且大概率是先喝一小口解渴，然后再稍微等会儿，就可以全部喝下去了）
2.平时我们感觉水冷得慢是因为我们当时不急着喝水，只会用手去触摸，有时候水温是 50 度，你手一摸好烫，然后就觉得水还没冷，先不喝。但其实它已经可以喝了。本质就是其实一杯沸水冷却到可以喝的程度其实比我们想像中的快。

2020-01-09 11:10:02 +08:00

回复了 xatest 创建的主题 › 问与答 › 征集一种对回复抽多个奖的随机算法，回复方案必感谢~

解释一下:
1.原理是给伪随机数生成器一个确定的种子,那么他的随机数生成也变得确定了.保证结果可重现.
2.用这个算法,就要等到明天 9 点 30 开奖,如果想立即开奖,也可以改成今晚 12 点的比特币价格或者其它国家的股市收盘价格(建议用开 /收盘价格,它是一个定值,而比特币时刻在变).
3.运行环境可以用在线 python 工具(比如 https://c.runoob.com/compile/9)或者指定 python 版本来保证结果可重现.
4.可以再多加几层混淆,但是我觉得没必要了.

2020-01-09 11:00:52 +08:00

回复了 xatest 创建的主题 › 问与答 › 征集一种对回复抽多个奖的随机算法，回复方案必感谢~

# -*- coding: UTF-8 -*-
import random

#明天开盘时的上证指数*100 的值
sh_value = 3083.39
#楼层总数
msg_count=1234

#初始化随机值
random.seed(sh_value * 100)
seed2 = random.randint(1,9999)
random.seed(seed2)

//开始抽奖
print "第一个中奖者楼层:%d" %random.randint(1,msg_count)
print "第二个中奖者楼层:%d" %random.randint(1,msg_count)
print "第三个中奖者楼层:%d" %random.randint(1,msg_count)
print "第四个中奖者楼层:%d" %random.randint(1,msg_count)
#如果上面有重复,后者用候补顶替
print "候补中奖者一:%d" %random.randint(1,msg_count)
print "候补中奖者二:%d" %random.randint(1,msg_count)

2020-01-09 10:44:35 +08:00

回复了 xatest 创建的主题 › 推广 › 本码农给老婆的钻戒/珠宝店做下推广，给 V 友们抽几个奖~

留言支持一下.

2020-01-09 09:51:18 +08:00

回复了 Dex7er 创建的主题 › Android › 请问有没有适合老年人操作的智能电视或者 TV APP 推荐一下？

有一个思路是:把电视设置成开机自动显示 AV 口或者 HDMI 口。直接跳过电视系统，显示机顶盒画面。

2019-10-30 14:23:54 +08:00

回复了 zhoushiya 创建的主题 › 分享发现 › 一大早来个好消息， Test result: IP NOT BLOCKED

同楼上,先是完全 unblocked,可以$$直连,然后今天发现可以 ping 通,但$$怎么都连不上.
遇到这种情况,建议中间再加一层 kcptun 就好了.

2019-10-18 15:02:48 +08:00

回复了 goldeye0351 创建的主题 › Apple › 创建了一个苹果的共享相册，带 GPS 的全球各地的风景的 livephoto，有人参与不？

eGlhbzE3MTc0QDEyNi5jb20=
你们都在国外吗,带上我

2019-04-04 15:46:49 +08:00

回复了 goodryb 创建的主题 › Apple › 亲测 140 元搞定 WiFi 无缝漫游，适合 iOS、windows 设备(部分)

是不是漏掉个关键点,就是尽量每个 ap 尽量不要相同频段,且尽量有较大差值.

2019-04-04 09:39:28 +08:00

回复了 baiyun888 创建的主题 › 奇思妙想 › 关于儿童定位的一个想法

时代技术不允许.主要技术壁垒就是电池.
当然,如果电池技术突破了.你说的这事就不是事了.

2018-12-05 09:58:32 +08:00

回复了 secsilm 创建的主题 › Python › JSON 对象 or JSON 字符串

@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,即纯文本的本质.

2018-12-04 17:31:39 +08:00

回复了 secsilm 创建的主题 › Python › JSON 对象 or JSON 字符串

@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 就可以了) 然而这就不在我们的讨论范围了.

2018-12-04 10:54:06 +08:00

回复了 secsilm 创建的主题 › Python › JSON 对象 or JSON 字符串

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

2018-09-10 11:42:21 +08:00

回复了 quickma 创建的主题 › 问与答 › 关于 KCPTUN

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

2018-09-10 10:48:44 +08:00

回复了 quickma 创建的主题 › 问与答 › 关于 KCPTUN

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

2018-08-10 17:29:57 +08:00

回复了 javaCoder 创建的主题 › 程序员 › TCP 粘包问题浅析及其解决方案

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

2018-08-10 17:22:59 +08:00

回复了 javaCoder 创建的主题 › 程序员 › TCP 粘包问题浅析及其解决方案

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

2018-05-30 12:01:35 +08:00

回复了 whereabouts 创建的主题 › 问与答 › 有可以加速 50～ 100 倍播放的视频播放器吗？假设硬盘带宽和显卡性能 OK 的情况下

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

2018-05-25 17:25:22 +08:00

回复了 Mmmmc 创建的主题 › 问与答 › 关于 Qt 的多线程问题.

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

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

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

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

2018-05-25 12:03:50 +08:00

回复了 Mmmmc 创建的主题 › 问与答 › 关于 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.

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

1 2 3 4

❮

❯