是什么导致TCP Window Full(WireShark)错误发送到WCF服务?

时间:2013-03-08 21:53:47

标签: wcf tcp

我们在Windows Server 2008 R2虚拟机上运行WCF数据收集服务。客户端是Win 7 x64盒子,应用程序是C#.NET 4 Windows Forms应用程序。该服务的主要目的是从客户端收集测试结果并根据该数据提供报告。 (它与SQL Server实例和Oracle实例接口,但这可能无关紧要。)

最近,当我们添加更多客户端时,我们开始看到数据传输丢失并且“服务端已达到”MaxOutboundConnectionsPerEndpoint quota(10)“错误,因此我们相应地调整了参数。

这种类型的错误消失了,但现在我们在服务器端收到“Faulted System.ServiceModel.Channels.ServerSessionPreambleConnectionReader + ServerFramingDuplexSessionChannel”错误。在服务器端运行WireShark被证明是徒劳的,因为它不会继续运行......可能是VM干扰了,我不知道。

在客户端运行WireShark产生了更多信息。当发送失败时,WireShark报告了几个“TCP Window Full”错误。

以下是来自服务器端的绑定def:

<bindings>
  <netTcpBinding>
    <binding name="bigBufferBinding"
             portSharingEnabled="false"
             maxBufferSize="1024000"
             maxBufferPoolSize="1000000"
             maxReceivedMessageSize="1024000"
             maxConnections="500"
             listenBacklog="250"
             sendTimeout="00:05:00"
             receiveTimeout="00:05:00">
      <readerQuotas maxDepth="200"
                    maxStringContentLength="65536"
                    maxArrayLength="32768"
                    maxBytesPerRead="4096"
                    maxNameTableCharCount="16384"/>
      <security mode="None"/>
    </binding>
  </netTcpBinding>
</bindings>

这是客户方:

<bindings>
  <netTcpBinding>
    <binding name="bigBuffer_ClientTcpBinding"
             maxBufferSize="1024000"
             maxBufferPoolSize="1000000"
             maxReceivedMessageSize="1024000"
             sendTimeout="00:00:30"
             receiveTimeout="00:00:30">
      <readerQuotas maxDepth="200"
                    maxStringContentLength="65536"
                    maxArrayLength="32768"
                    maxBytesPerRead="4096"
                    maxNameTableCharCount="16384"/>
      <security mode="None"/>
    </binding>
  </netTcpBinding>
</bindings>

我尝试增加maxBufferSize,maxBufferPoolSize和maxReceivedMessageSize属性,但是任何显着的增加都会导致服务无法启动。我不确定问题出在哪里。

我需要在这看什么?我们没有大量的数据(10个客户端偶尔会发送60到40000字节的数据到服务中),所以我们肯定不应该压倒WCF服务。我认为它与如何配置TCP有关,但这只是猜测。它运行在千兆网络上,禁用了巨型数据包。

在数千次尝试中,我们每天有15到40次数据失败。我们添加了重试,因此数据最终会到达那里(在大多数情况下是第二次尝试) - 这并没有真正解决问题,但它让我的背部产生了生产,我们实际上并没有丢失任何数据。

为了平息预期的抗议和责骂,我们将序列化数据写入磁盘文件失败(两次!),所以如果数据无法进入数据库,我们可以重新提交。我们从未真正丢失任何数据。

想法?任何帮助表示赞赏,可根据要求提供更多数据。

谢谢, 戴夫

0 个答案:

没有答案