c# - 使用非单向方法的 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);
}

这里是绑定(bind)配置的摘录:

<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 的任何调用

现在，我的问题:

• 这是怎么回事？

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

• 假设我选择修复 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 一样简单。