- 主题:socket接收几百k字节的报文，32k字节收一次，间隔0.5秒超时，概
RT：
本地的服务端一次性调用send接口发送几百k字节的报文。
客户端（python写的）用recv接口，一次性接收32k字节，一次接收完后，设置下次recv的超时时间为0.5秒，发现概率性收不全就超时了。
但是我用简单测试程序，怎么也模拟不出这种情况，基本都是在很短时间内能收完。
哪位大神知道大概啥原因？
--
FROM 221.231.166.*
500ms的超时放在非实时系统用户态上能行么？
【 在 elephant 的大作中提到: 】
: RT：
: 本地的服务端一次性调用send接口发送几百k字节的报文。
: 客户端（python写的）用recv接口，一次性接收32k字节，一次接收完后，设置下次recv的超时时间为0.5秒，发现概率性收不全就超时了。
: ...................
--
FROM 213.95.148.*
你说的这个道理，我也知道。。。
但是我怎么也没模拟出来。
我写了个简单的客户端服务端，每10秒发送300k字节，其它条件和问题代码基本一样。
我甚至开了若干个死循环进程，模拟CPU使用率很高甚至100%的情况，也没有复现。
【 在 moudy 的大作中提到: 】
: 500ms的超时放在非实时系统用户态上能行么？
--
FROM 221.231.166.*
正常肯定没问题，500ms是很大的间隔了，x86上一个tick也才15ms左右
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers
这种一般不是os问题，是自己写的代码的问题
【 在 moudy 的大作中提到: 】
: 500ms的超时放在非实时系统用户态上能行么？
--
FROM 61.48.128.*
datagram类的协议一次发不了几百K
【 在 elephant (elephant) 的大作中提到: 】
: RT：
: 本地的服务端一次性调用send接口发送几百k字节的报文。
: 客户端（python写的）用recv接口，一次性接收32k字节，一次接收完后，设置下次recv的超时时间为0.5秒，发现概率性收不全就超时了。
: ...................
--
FROM 113.108.77.*
你有检查发送成功了吗
【 在 elephant 的大作中提到: 】
: RT：
: 本地的服务端一次性调用send接口发送几百k字节的报文。
: 客户端（python写的）用recv接口，一次性接收32k字节，一次接收完后，设置下次recv的超时时间为0.5秒，发现概率性收不全就超时了。
: ...................
--
FROM 114.249.23.*
如果你用的是udp就有丢包的概率，udp在短时间内发送了大量的包，就会丢包，一次发几百k的包，实际上系统是给你拆成几百个包发出去的，就有丢包的可能，所以如果你用的是udp，收和发一次性尽量不要超过1k，发包频率也不要太快，最好每一个包都有校验，才能保证不丢包，如果是TCP是不会丢包的，除非你程序有问题，不过即使是TCP我自己发这么大的包都是拆包发的，我从来不会一次性发这么大的包，不过我都是用C，没用过python，不知道python是什么样的机制
【 在 elephant 的大作中提到: 】
: RT：
: 本地的服务端一次性调用send接口发送几百k字节的报文。
: 客户端（python写的）用recv接口，一次性接收32k字节，一次接收完后，设置下次recv的超时时间为0.5秒，发现概率性收不全就超时了。
: ...................
--
修改:smthxes FROM 27.203.33.*
FROM 27.203.33.*
没仔细看MS的文档吧？只是clock tick默认是15ms左右，高精度定时器的expiration可以调整到1ms以内。
【 在 lambdai 的大作中提到: 】
: 15ms？这么大？即使是1ms也
: 这是说给driver的api就这么差吗？这比userspace的还糟啊
: 我是不是误解了什么？
: ...................
--
FROM 114.240.244.*