如何配置 C# Web 服务客户端以并行发送 HTTP 请求标头和正文?

发布于 2024-08-24 05:14:47 字数 1313 浏览 7 评论 0原文

我使用的是在 VS2008 .Net 3.5 中生成的传统 C# Web 服务客户端,继承自 SoapHttpClientProtocol。这是连接到用 Java 编写的远程 Web 服务。

所有配置都是在客户端初始化期间在代码中完成的,如下所示:

        ServicePointManager.Expect100Continue = false;
        ServicePointManager.DefaultConnectionLimit = 10;

        var client = new APIService
        {
            EnableDecompression = true,
            Url = _url + "?guid=" + Guid.NewGuid(),
            Credentials = new NetworkCredential(user, password, null),
            PreAuthenticate = true,
            Timeout = 5000 // 5 sec
        };

一切正常,但执行最简单的方法调用所需的时间几乎是网络 ping 时间的两倍。而 Java 测试客户端花费的时间与网络 ping 时间大致相同:

C# client ~ 550ms
Java client ~ 340ms
Network ping ~ 300ms

在分析会话的 TCP 流量后发现以下内容:

基本上,C# 客户端按以下顺序发送 TCP 数据包。

Client Send HTTP Headers in one packet.
Client Waits For TCP ACK from server.
Client Sends HTTP Body in one packet.
Client Waits For TCP ACK from server.

Java 客户端按以下顺序发送 TCP 数据包。

Client Sends HTTP Headers in one packet.
Client Sends HTTP Body in one packet.
Client Revieves ACK for first packet.
Client Revieves ACK for second packet.
Client Revieves ACK for second packet.

无论如何,是否可以将 C# Web 服务客户端配置为像 Java 客户端那样并行发送标头/正文?

非常感谢任何帮助或指示。

I am using a traditional C# web service client generated in VS2008 .Net 3.5, inheriting from SoapHttpClientProtocol. This is connecting to a remote web service written in Java.

All configuration is done in code during client initialization, and can be seen below:

        ServicePointManager.Expect100Continue = false;
        ServicePointManager.DefaultConnectionLimit = 10;

        var client = new APIService
        {
            EnableDecompression = true,
            Url = _url + "?guid=" + Guid.NewGuid(),
            Credentials = new NetworkCredential(user, password, null),
            PreAuthenticate = true,
            Timeout = 5000 // 5 sec
        };

It all works fine, but the time taken to execute the simplest method call is almost double the network ping time. Whereas a Java test client takes roughly the same as the network ping time:

C# client ~ 550ms
Java client ~ 340ms
Network ping ~ 300ms

After analyzing the TCP traffic for a session discovered the following:

Basically, the C# client sent TCP packets in the following sequence.

Client Send HTTP Headers in one packet.
Client Waits For TCP ACK from server.
Client Sends HTTP Body in one packet.
Client Waits For TCP ACK from server.

The Java client sent TCP packets in the following sequence.

Client Sends HTTP Headers in one packet.
Client Sends HTTP Body in one packet.
Client Revieves ACK for first packet.
Client Revieves ACK for second packet.
Client Revieves ACK for second packet.

Is there anyway to configure the C# web service client to send the header/body in parallel as the Java client appears to?

Any help or pointers much appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

甜中书 2024-08-31 05:14:47

感谢 Rob 的回复,最终我选择使用添加服务引用/WCF 代理生成,默认情况下会执行此操作。可能是因为它在底层使用了较新的 HTTP 库。

对于返回复杂对象的原始数组的 SOAP 方法,我确实遇到了一些 WCF 代理生成问题(即:返回包含对象数组的对象工作正常)。为了解决这个问题,您要么必须将数组包装在对象中,要么将 SOAP 服务器配置从 RPC 切换到 DOCUMENT(这就是我们所做的)。

Thanks for the reply Rob, eventually I opted to use the Add Service Reference / WCF proxy generation, which does this by default. Probably because it's using newer HTTP libraries underneath.

I did have a few WCF proxy generation issues with SOAP methods that return raw arrays of complex objects (i.e.: returning an object that contains an array of objects worked fine). To get round this you either have to wrap your arrays in objects, or switch the SOAP server config from RPC to DOCUMENT (which is what we did).

把回忆走一遍 2024-08-31 05:14:47

我认为您可以使用继承的 EndGetRequestStream 方法来破解 SoapHttpClientProtocol。将其保存到缓冲区,直到请求完成。然后创建自己的流并立即将其全部推出。

I think you can use the inherited EndGetRequestStream method to hack the SoapHttpClientProtocol. Save that to a buffer until the request has finished. Then make your own stream and push it all out at once.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文