Windows时钟更改上的NetworkStream超时 [英] NetworkStream TimedOut on Windows Clock Change

查看:65
本文介绍了Windows时钟更改上的NetworkStream超时的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

In our c# application, we are using a TcpClient listening for messages coming from our clients.

建立连接后,我们在套接字上设置了超时时间,以避免出现无用的打开连接.

When the connection is established we set a time out on the socket, to avoid to have useless open connections.

将Windows时间更改为将来的时间时,我们遇到了奇怪的行为.

We encountered a strange behaviour when we change the Windows Time to a future time.

只是要清楚.

NetworkStream.ReadTimeout设置为30秒.

NetworkStream.ReadTimeout set to 30seconds.

起始情况:Windows时间= 10:00:00(UTC)

Starting situation: Windows Time = 10:00:00 (UTC)

我们将时间手动更改为10:01:00(UTC)

We manually change time to 10:01:00(UTC)

立刻我们就超时了.

这是Windows中的正常行为,还是我们的实现中发生了不好的事情?

Is this a normal behavior in Windows or something bad is happening in our implementation?

系统参考:Windows 7 x64 .Net 4.5

System references: Windows 7 x64 .Net 4.5

推荐答案

这是Windows中的正常行为,还是我们的实现中发生了不好的事情?

Is this a normal behavior in Windows or something bad is happening in our implementation?

根据我的理解,这应该是默认行为.您正在从TcpClient设置networkstream的timeout属性,我认为该属性将与本地时间系统配合使用以比较该timeout属性.它作为 预期.

Per my understanding, this should be the default behavior. You are setting the timeout property of networkstream from TcpClient, I think the property will work with local time system to compare that timeout property. It works as expected.

顺便说一句,为什么要更改本地时间?如果有问题,您能解释更多吗?

此致,


这篇关于Windows时钟更改上的NetworkStream超时的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆