使用非单向方法的 WCF 中的竞争条件

Question

我正在设计一个客户端-服务器聊天应用程序（事实上我不是，但让我们假装我是:)），我对我经历过的一些竞争条件感到有点困惑。

假设我有以下代码：

public interface IServer
{
  [OperationContract(IsOneWay = false)]
  [FaultContract(typeof(ChatException))]
  void BroadcastMessage(string msg);
}

public class Server : IServer 
{
  void BroadcastMessage(string msg) // I'm not mentionning the try/catch/throw FaultException here for readability purposes
  {
    foreach (IClientCallback c in callbacks){
      c.ReceiveMessage(msg);
    }

  }
}

public interface IClientCallback
{
  [OperationContract(IsOneWay = true)]
  void ReceiveMessage(string s);
}

这是绑定配置的摘录：

<endpoint address="" 
binding="netTcpBinding" 
bindingConfiguration="DuplexBinding" 
contract="IServer" />

 <binding name="DuplexBinding" sendTimeout="00:01:00">
   <reliableSession ordered="true" inactivityTimeout="00:05:00" enabled="true"/>
   <security mode="None">
     <transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
     <message clientCredentialType="Windows" />
   </security>
 </binding>

这当然是某种伪 C#，为了清楚起见，我删除了很多不相关的代码。

现在进入正题： 这段代码不会工作。 当我调用 BroadcastMessage 时，该方法永远不会返回，并且最终在客户端出现超时。 如果我在服务器端调试，一切看起来都很好（我从 BroadcastMessage 方法返回，正如人们所期望的那样，并且我没有阻止任何 ReceiveMessage 单向调用）

这里有两种方法来修复此代码：

1. 删除FaultContract 和将 BroadcastMessage 方法声明为 oneway=true
2. 将消息广播给每个人，但初始发送者

我的第一个猜测是客户端正在等待服务器返回，因此无法处理来自服务器的传入 ReceiveMessage 调用，因此阻塞服务器，但 ReceiveMessage 被声明为单向，并且调试服务器表明它不会阻塞对 ReceiveMessage 的任何调用

现在，我的问题：

• 发生了什么事？

• 还有其他方法可以解决这个问题吗？ （也许通过调整绑定配置？）

• 假设我选择修复 2（即不广播回发送者），如果服务器调用我的 ReceiveMessage 回调（因为其他人向我发送了消息），会发生什么情况正在等待我自己的 BroadcastMessage 调用完成？

• 我读到 OneWay 调用并不完全是单向的，并且服务器仍然等待来自另一端的 HTTP 响应。 有这方面的详细信息吗？ 具体来说，当客户端在远程调用中被阻止时，是否能够响应此类 http 响应？

编辑：服务器端的 Console .net 3.5，客户端的 Winforms .net 3.5

Answer 1

这听起来像是一个僵局，可能是由于同步上下文造成的。 什么是客户？ 维窗体？ 世界和平基金会？ WCF 尊重同步上下文，这对于 winforms 和 WPF 来说意味着“切换到 UI 线程”。 如果您在 UI 线程上发出阻塞请求，则游戏结束。

尝试在后台线程上执行 WCF 请求，以便 UI 线程可用于处理传入请求； 这可以像使用 ThreadPool 或 BackgroundWorker 一样简单。

Answer 2

尝试将此属性添加到服务的具体实现中：

[System.ServiceModel.ServiceBehavior(UseSynchronizationContext=false)]
public class Server : IServer {}

其次，尝试打开 WCF 跟踪，看看 WCF 实现的内部是否发生了一些让您感到悲伤的事情。 我遇到了一些非常奇怪的错误，只有当我进入跟踪并发现正在发生的实际错误消息时，这些错误才有意义。

跟踪 WCF 服务