在实时环境中使用 WCF 或 Sockets 进行通信？
我有一个场景，我需要跨 2 个客户端发送一系列数据。
数据包括序列化 XML，其中包含其他客户端需要做出反应的命令。
我还需要通过网络发送图像，因为我需要以视频/音频聊天的形式提供聊天设施。
我希望两者都有一个单一的通信媒介，因为消息/命令的数量可能很少。
WCF 还是套接字？
I have a scenario where I need to send a series of data across 2 clients.
The data includes Serialized XML that will contain commands that the other client will need to react to.
I will also need to send images across the wire as I need to provide a chat facility in the form of video/audio chat.
I would like a single communication medium for both, as the number of messages/commands might be a few.
WCF or Sockets?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
WCF 是用于构建面向服务的应用程序的 API。我不认为视频/语音聊天是这样的应用程序。
首先，此类应用需要哪些传输功能？我对语音/视频传输的了解很差，但我期望：
所以通过简单地描述这三个期望我已经看到了问题。 WCF 内置 Net.Tcp 绑定 不允许双工通信和流式传输。另请注意，通过 WCF 进行的 Net.tcp 通信的性能比普通套接字通信差得多。这是因为 WCF 简化了很多事情，但这些简化和概括会减慢处理速度。
同样基于所选算法这可能是一个问题。
在这里您可以找到有关 Silverlight 4 中视频聊天的一些说明。Silverlight 允许使用 WCF和 net.tcp 绑定，但通信仍然是在套接字上开发的。
在这里您可以找到广泛使用的 IP 语音协议的说明 - 用于数据传输的 RTP RTCP 用于协调和 QoS。这些协议也用于视频传输。通过谷歌搜索，我找到了.NET的实现（我不知道实现有多好）是的，我刚刚用过谷歌......）
WCF is API for building service oriented applications. I don't thing that Video/Voice chat is such kind of application.
First of all what transport features do you require for such application? My knowledge of Voice/Video transmission is very poor but I expect:
So by simply describing these three expectations I already see the problem. WCF build-in Net.Tcp binding does not allow duplex communication and streaming together. Also be aware that performance of Net.tcp communication over WCF is much worse than plain socket communication. It is because WCF simplifies a lot of things but those simplification and generalizations slows processing.
Also based on selected algorithm this could be a problem.
Here you can find some describtion of Video chat in Silverlight 4. Silverlight allows WCF and net.tcp binding but the communication is still developed on sockets.
Here you can find description of widely used protocols for voice over IP - RTP for data transmission and RTCP for coordination and QoS. These protocols are also used for video transmission. By googling I found implementation for .NET (I don't know how good the implementation is, I just used google ...)
以下是我会考虑的一些事情：
如果您预计有几种不同类型的客户端连接到您的服务器，那么 WCF 可能会很有用。也许将来您可能想让其他人编写客户端，或多或少独立于您。另一方面，如果它是一个封闭的系统，那么您可能更喜欢编写自己的套接字代码。
WCF 为您提供了更高级别的抽象，因此您可以更快地编写系统。特别是，像 XML 编码和会话管理这样的事情实际上并不是您的应用程序域的一部分，因此您不想在它们上花费太多时间。但更高的抽象通常会带来性能成本，因为抽象层比任何一个应用程序的需求都更通用。使用普通套接字，您可以根据自己的需求定制系统，这可能会带来更高的性能（以更繁琐的开发和错误修复为代价）。
您可能希望在单独的流中发送数据/命令和视频。据推测，数据/命令必须通过可靠的传输方式发送，但视频可能会遭受一些损失。或者，视频可能应该以高 QOS 发送，而数据/命令可能会出现延迟。我从未真正使用过 QOS，因此我不知道这里存在什么问题，但它可能会影响您对 WCF 的决定（无论是有利还是不利）。
您可以将服务器托管在其自己的进程中或在 IIS 中。如果您自己托管，那么您可以按照自己的方式做事。我相信 WCF 和 IIS 是好朋友，因此如果您考虑使用 IIS，那么 WCF 可能会让生活变得更加轻松。如果您选择 IIS（或任何已建立的 Web 服务器）而不是自己的主机，则可以利用它们的基础设施 - 可扩展性、可靠性、加密等。缺点是您可能会被锁定到该服务器，但这在实践中可能不是问题。
根据您的环境，您也许能够混合和匹配各种技术和功能。例如，我们有一个听起来与您的系统有点相似的系统，我们选择了：客户端中的普通套接字；服务器中的普通套接字，但可以选择在 Apache 中托管服务器；一个定制的 XML 库，可以满足我们的需要；嵌入式 OpenSSL； COM 是系统的核心，但依赖于 .NET。特别是，我们在第一个原型中使用了 SOAP，因为它的消息传递和 RPC 非常适合我们的设计，但发现它增加了太多复杂性，因此用我们自己的协议替换了它。
如果您有时间，那么我建议您在 WCF 中构建一个快速原型，看看您的想法。希望它能成功，但如果没有成功，不要害怕扔掉它。主要原则是尽可能高效地为客户提供最大的业务价值，这通常意味着您应该将精力花在应用程序领域而不是基础设施上。但同时不要忽视次要原则，例如性能、可靠性、可伸缩性、可维护性、可扩展性等。
Here are some of the things I would think about:
WCF might be useful if you anticipate several different kinds of client connecting to your server. Maybe in the future you might want to let other people write clients, more or less independent of you. On the other hand, if it's a closed system then you might prefer to write your own sockets code.
WCF gives you a higher-level abstraction, so presumably you can write your system more quickly. In particular, things like XML encoding and session management are not really part of your application domain and so you don't want to spend much time working on them. But higher abstraction typically involves a performance cost, because the abstraction layer is more general-purpose than any one application needs. With plain sockets you can tailor your system to your own needs, and that might allow for higher performance (at the cost of more fiddly development and bug-fixing.)
You might want to send your data/commands and video in separate streams. Presumably the data/commands must be sent over a reliable transport, but the video can suffer some loss. Or maybe the video should be sent with a high QOS whereas the data/commands can suffer latency. I've never actually used QOS and so I don't know what the issues are here, but it could impact your decision about WCF (either favourably or negatively.)
You can host your server in its own process or in IIS. If you host it yourself then you can do things your own way. I believe that WCF and IIS are good friends, so if you're thinking IIS then WCF might make life a lot easier. If you choose IIS (or any established web server) over your own host, you can take advantage of their infrastructure - scalability, reliability, encryption, and so on. The downside is that you might get locked into that server, but that might not be a problem in practice.
Depending on your environment you may be able to mix and match the various technologies and features. For example, we have a system that sounds vaguely similar to yours and we opted for: plain sockets in the client; plain sockets in the server but with an option to host the server in Apache instead; a custom XML library that does just what we need; embedded OpenSSL; COM at the core of the system but with dependencies on .NET. In particular, we used SOAP in our first prototype because its messaging and RPC was a perfect match for our design, but found it added too much complexity and replaced it with our own protocol.
If you have the time, then I suggest that you build a quick prototype in WCF and see what you think. Hope that it works out, but don't be afraid to dump it if it doesn't. The main principle is to deliver maximum business value to your customers as efficiently as possible, and that usually means that you should spend your efforts in your application domain rather than on infrastructure. But at the same time don't ignore secondary principles such as performance, reliability, scalability, maintenance, extensibility, and so on.
WCF 或套接字？？？这些不是替代方案：WCF 包括用于 TCP/IP 通信的 NetTcpBinding 和 NetPeerTcpBinding。
如果您的客户端都是 Windows，则应该使用 WCF。
WCF or Sockets??? These are not alternatives: WCF includes the NetTcpBinding and NetPeerTcpBinding, for TCP/IP communication.
If your clients are both Windows, you should use WCF.