KCP报文中时标单位为毫秒,对于32位正整数而言,最多49天就溢出了……当这种情况确时发生时,什么出现什么情况,有没有实际测试过?谢谢!!
carvr3hs1#
根本不会溢出,是循环的,你没看懂,你找找以前的issue讨论过的。
ycl3bljg2#
谢谢!明白了,确实不用担心溢出……另外,从这个角度而言,若将conv/ts/sn/una几个属性都改为16位的貌似也能满足实际应用,还能省点儿带宽……
wribegjk3#
也不会浪费带宽,本身encode的时候还是按照u16来处理的,也就是2个字节,其实是省点内存。。。
13z8s7eq4#
你确定?Segment貌似就是24字节报头吧。这里面就有4个字节是时间戳。
4条答案
按热度按时间carvr3hs1#
根本不会溢出,是循环的,你没看懂,你找找以前的issue讨论过的。
ycl3bljg2#
谢谢!明白了,确实不用担心溢出……
另外,从这个角度而言,若将conv/ts/sn/una几个属性都改为16位的貌似也能满足实际应用,还能省点儿带宽……
wribegjk3#
也不会浪费带宽,本身encode的时候还是按照u16来处理的,也就是2个字节,其实是省点内存。。。
13z8s7eq4#
也不会浪费带宽,本身encode的时候还是按照u16来处理的,也就是2个字节,其实是省点内存。。。
你确定?Segment貌似就是24字节报头吧。这里面就有4个字节是时间戳。