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个字节是时间戳。