确定 .NET CF 中 Web 服务调用传输的数据大小
我正在开发 .NET CF 客户端应用程序并使用 Web 服务进行数据传输。 我正在使用 SharpZipLib 压缩传输的数据集，因此我知道传输的字节数组的大小。
我想知道是否有一种简单的方法来确定一次调用的完整请求大小（html headerder、soap 信封和真实数据）。 我真的很想最大限度地减少 GPRS 连接成本。
谢谢...
I'm developing a .NET CF client application and using web services for data transfer. I'm using SharpZipLib to compress transfered datasets so I know the size of the transfered byte array.
I wonder is there an easy way to determine to complete request size (html headerder, soap envelops and the real data) for a single call. I really want to minimize the GPRS connection costs.
Thanks...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
重新回答总体问题； 抱歉，我不知道是否需要使用网络跟踪器......
但是； 我可以谦虚地建议数据集和 SOAP 并不总是带宽受限设备上的最佳选择吗？ 压缩效果很好，但并不总是理想。 除非您需要所提供的功能，否则可以使用更简单的协议（例如 POX，可能使用内置协议压缩（GZIP/Deflate））。
另一方面......如果您可以将事物表达为消息，那么序列化器如 protobuf -net 可能有用（与原始二进制帖子结合）； 它们的数据非常密集（因此尝试使用压缩不可避免地会增加大小）。 但是，您需要在客户端进行自己的数据/更改跟踪，并且 RPC 堆栈尚未完成（我已经有了工作原型代码，但我还没有提交它，因为我仍然对其进行单元测试）。 服务器也会有所不同（即不是 asmx 或其他任何东西 - 可能是经过操纵的处理程序或 MVC 控制器）。
作为另一种选择 - ADO.NET 数据服务可能会令人感兴趣，特别是在 JSON 模式下（对于带宽，再次使用协议压缩）。
Re the overall question; sorry, I don't know short of using a network tracer...
However; can I humbly propose that datasets and SOAP are not always the best choice on bandwidth restricted devices? Compression does a good job, but not always ideal. Unless you need the features offered, simpler protocols are available (such as POX, perhaps using inbuilt protocol compression (GZIP/Deflate)).
At the other end of things... if you can phrase things as messages, then serializers like protobuf-net might be useful (combined with raw binary posts); they are very data dense (such that attempts to use compression inevitably increases the size). However, you'd need to do your own data/change tracking at the client, and the RPC stack is as-yet incomplete (I've got working prototype code, but I haven't committed it yet, as I'm still unit testing it). The server would also be different (i.e. not an asmx or whatever - perhaps a rigged handler or MVC controller).
As another alternative - ADO.NET Data Services might be of interest, especially in JSON mode (for bandwidth, again using protocol compression).
WCF 支持消息跟踪，这可以让您看到生成的 SOAP+消息的大小。 您可以使用这些跟踪文件来确定您正在寻找的内容，尽管通过对通信进行压缩，发送的字节将不那么明显。 对于实际的电线尺寸，wireshark 将是一个不错的选择。 或者您可以压缩从 WCF 跟踪中提取的消息并获得一个粗略的想法。
WCF supports message tracing which would let you see the size of the generated SOAP+Message. You could use these trace files to determine what you are looking for although with compression on your communications the bytes sent will be less obviously. For the actual on the wire size wireshark would be a good bet. Or you could zip the message pulled from the WCF trace and get a rough idea.
Wireshark 是著名的协议分析工具。 然而，这对于您的需求来说可能有点过分了。
另请查看 Fiddler。 这更容易，并且允许您监视来自模拟器的流量。
tcpmon 是一个位于服务器和客户端之间的 Java 实用程序。 您需要在应用程序中编辑端点以连接到 tcpmon 并配置 tcpmon 以将所有请求代理到实际的 Web 服务。 花费的时间不会超过 10 分钟 - 这是一个非常简单的实用程序。 然后您可以监视 tcpmon 中的原始请求或使用 Fiddler 捕获流量。
Wireshark is a famous protocol analyzer tool. However it may be an overkill for your needs.
Also checkout Fiddler. This is easier and it will allow you to monitor traffic from an emulator.
tcpmon is a Java utility that can sit between a server and a client. You need to edit the endpoint in your application to connect to tcpmon and configure tcpmon to proxy all requests to the actual web service. It shouldn't take more than 10 minutes - it is a very simple utility. Then you can monitor the raw requests in tcpmon or capture traffic with Fiddler.