网络电话永远不会超时(web calls never timing out)

网络电话永远不会超时(web calls never timing out)

我有许多使用各种Web技术的应用程序，例如SOAP，WCF服务或简单的XmlReader。 然而，如果互联网连接在错误的时间遇到​​问题，它们似乎都会遇到错过超时和无限悬挂的问题。

我已经将所有场景中的超时设置为小的，例如对于wcf

closeTimeout="00:00:15" openTimeout="00:00:15" receiveTimeout="00:00:15" sendTimeout="00:00:15"

或肥皂

_Session.Timeout = (int)TIMEOUT.TotalMilliseconds;

这些超时通常会被击中，但是看起来有一些特殊情况，如果互联网在正确的时间退出，呼叫将挂起并且永远不会超时（使用同步呼叫）。

我正在考虑每次拨打电话时启动一个计时器，并在计时器到期时使用相应的.Abort()函数取消呼叫。 但是，我想知道是否有更简单的方法来解决问题并确保超时被击中。

有谁知道为什么会发生这种情况，如果是这样，干净/简单/好的方法是什么，以确保呼叫总是超时？

I have a number of applications using various web technologies such as SOAP, WCF Services, or just simple XmlReader. However they all seem to suffer the same problem of missing the timeout and hanging infinitely if the internet connection suffers problems at the wrong time.

I have set the timeout in all scenarios to something small, e.g. for wcf

closeTimeout="00:00:15" openTimeout="00:00:15" receiveTimeout="00:00:15" sendTimeout="00:00:15"

or for soap

_Session.Timeout = (int)TIMEOUT.TotalMilliseconds;

These timeouts do generally get hit, however it appears there is some special case where if the internet drops out at the right time, the call will hang and never time out (using synchronous calls).

I was considering starting up a timer every time I make a call, and using the appropriate .Abort() function if the timer expires to cancel the call. However, I was wondering if there was a simpler way to fix the issue and ensure the timeout gets hit.

Does anyone know why this occurs, and if so what a clean/simple/good way is to ensure the calls always time out?

最满意答案

我猜它为什么会发生，但没有给出解决方案:(

我怀疑它正在陷入DNS解析。 我已经看到了“不计数”的各种情况 - 例如，它最终发生在异步调用的启动线程上，或者它绝对没有被包含在超时中。

如果您能够通过拔出网络电缆来重现这一点，我建议使用Wireshark来确认我的猜测 - 这至少可以提出进一步的调查途径。 也许.NET堆栈中的某个地方存在DNS超时，通常是无限的，但可以调整，例如。

I can guess at why it occurs, but without giving a solution :(

I suspect it's getting caught up on DNS resolution. I've seen various situations where that "doesn't count" - e.g. where it ends up happening on the initiating thread of an asynchronous call, or where it's definitely not been included in timeouts.

If you're able to reproduce this by pulling out your network cable, I'd suggest using Wireshark to confirm my guess - that would at least suggest further avenues for investigation. Maybe there's a DNS timeout somewhere in the .NET stack which is normally infinite but which can be tweaked, for example.