WCF流传输缓冲 [英] WCF Streaming Transport Buffering

查看:64
本文介绍了WCF流传输缓冲的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近将NetTcp Streaming绑定切换到CustomBinding,因此可以使用自定义GZip编码.
压缩效果很好.  不过,我现在看到的是NetTcp绑定中没有的异常行为.

I recently switched a NetTcp Streaming binding over to a CustomBinding so I could make use of the custom GZip encoding.
The compression works great.  However I am now seeing a peculiar behavior that wasn't present in my NetTcp Binding.

1) 当服务器写入流时,该信息将被缓冲,直到该流具有大约4MB的数据为止.   
2) 
如果客户端在几分钟内没有收到任何传递给它的信息,则即使它正在写入服务器端,它也会超时.
我已经成功地解决了这一问题,方法是编写了一个保持活动机制,该机制可以监视流并每分钟一次将4MB的块转储到该流上,但这是我想要摆脱的可怕的丑陋方法.

所以我的问题是双重的:
a)流写入哪个缓冲区以及如何控制它.  是否可以使用某种机制使流始终将信息传递给客户端而不是等待?
B)我如何诊断确切的超时时间.  (除非您要提供有关如何解释跟踪文件的详细信息,否则请不要使用打开跟踪"来回应-我从来都无法为 调试超时)

1)  When the server writes to the stream, this information is buffered until the stream has approximately 4MB of data.   
2)  If the client doesn't get any information passed to it for several minutes it times out- even if the server side is being written to. 

I've successfully worked around this by writing a keepalive mechanism that monitors the stream and dumps 4MB chunks onto it once a minute- but this is a horribly ugly hack that I'd like to get rid of.

So my questions are twofold:
a) What buffer is the stream writing to and how do I control this.  Is there some mechanism I could use to make the stream always pass the information to the client rather than waiting?
B) How do I diagnose exactly what timeout is being hit.  (Please don't respond to this with 'Turn on Tracing' unless you are going to provide details on how to interpret the trace files- I've never been able to make heads or tails of the trace files for debugging timeouts)

这是我的配置:

Here are my configurations:

客户:

            < customBinding>
                < binding name =" StreamingClientCustomBinding" closeTimeout ="00:01:02"
                    openTimeout ="00:01:12" receiveTimeout ="01:00:12" sendTimeout ="01:01:12">
                    < windowsStreamSecurity/>
                    < gzipMessageEncoding innerMessageEncoding =" binaryMessageEncoding" />
                    < tcpTransport maxBufferPoolSize ="1"; maxReceivedMessageSize ="2147483647"
                        connectionBufferSize ="256192" channelInitializationTimeout ="00:00:30"
                        maxPendingConnections ="100". maxOutputDelay ="00:00:01"; maxPendingAccepts ="10"
                        transferMode =流式" listenBacklog ="200" portSharingEnabled ="true"; />
                </binding>
            </customBinding>

            <customBinding>
                <binding name="StreamingClientCustomBinding" closeTimeout="00:01:02"
                    openTimeout="00:01:12" receiveTimeout="01:00:12" sendTimeout="01:01:12">
                    <windowsStreamSecurity />
                    <gzipMessageEncoding innerMessageEncoding="binaryMessageEncoding" />
                    <tcpTransport maxBufferPoolSize="1" maxReceivedMessageSize="2147483647"
                        connectionBufferSize="256192" channelInitializationTimeout="00:00:30"
                        maxPendingConnections="100" maxOutputDelay="00:00:01" maxPendingAccepts="10"
                        transferMode="Streamed" listenBacklog="200" portSharingEnabled="true" />
                </binding>
            </customBinding>

服务器:

Server:

推荐答案

这是不正常的.请给我发送缩小比例的副本(不包含您的业务逻辑).请将整个按比例缩小的VisualStudio解决方案压缩为一个zip文件,然后通过以下电子邮件与我联系 cts-enamulkh@live.com

This is unsual. Please send me a scale-down repro (without your business logics). Please zip the entire scale-down VisualStudio solution into a single zip file and email me at cts-enamulkh@live.com


这篇关于WCF流传输缓冲的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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