WCF或实时环境中的通信套接字？

Question

我有一个场景，我需要发送2个客户端的一系列数据。

数据包含序列化XML，其中包含其他客户端需要作出反应的命令。

我还需要通过电线发送图像，因为我需要提供视频/音频聊天形式的聊天工具。

我希望为这两种通信媒体提供一个通信媒体，因为消息/命令的数量可能会很少。

WCF或套接字？

Answer 1

WCF是构建面向服务的应用程序的API。我不知道视频/语音聊天是这种应用程序。

首先您需要什么传输功能来实现这种应用？我的语音/视频传输的知识是非常差的，但我希望：

其中客户端连接到聊天服务器

• 全双工通信，发送自己的语音/视频数据，并接收其他客户端的语音/视频数据。
• 数据流 - 数据量可能相当大，因此在开始阅读数据时使用数据会很好。此外，一些编码算法应该用于流媒体。
• 服务质量 - 控制可持续的传播速度。 （如果你想进行会议视频聊天，你还需要协调多个流）

所以通过简单地描述这三个期望，我已经看到了问题。 WCF内置Net.Tcp绑定does not allow duplex communication and streaming together。另请注意，通过WCF的Net.tcp通信性能比普通套接字通信要差得多。这是因为WCF简化了很多事情，但这些简化和概括会减慢处理速度。

也基于选定的算法this可能是一个问题。

Here您可以在Silverlight 4中找到一些视频聊天的说明.Silverlight允许WCF和net.tcp绑定，但通信仍在套接字上开发。

Here你可以找到广泛使用的IP语音协议的描述 - 用于数据传输的RTP和用于协调和QoS的RTCP。这些协议也用于视频传输。谷歌搜索，我发现implementation为.NET（我不知道如何实施好是，我只是用谷歌...）

Answer 2

WCF or Sockets ???这些不是替代方案：WCF包括用于TCP/IP通信的NetTcpBinding和NetPeerTcpBinding。

如果你的客户都是Windows，你应该使用WCF。

Answer 3

这里有一些事情我曾经想：

WCF可能是如果您预计有几种不同类型的客户端连接到您的服务器，则会很有用也许将来你可能想让其他人写客户，或多或少独立于你。另一方面，如果它是一个封闭的系统，那么你可能更愿意编写自己的套接字代码。

WCF为您提供更高级别的抽象，所以大概您可以更快地编写您的系统。尤其是，XML编码和会话管理等功能并不是真正成为应用程序域的一部分，因此您不需要花太多时间来处理它们。但更高的抽象通常涉及性能成本，因为抽象层比任何应用程序需要更通用。使用普通套接字，您可以根据自己的需要量身定制系统，这可能会提高性能（代价是更加棘手的开发和bug修复）。

您可能希望将数据/命令和视频分开的流。据推测，数据/命令必须通过可靠的传输方式发送，但视频可能会遭受一些损失。或者，应该以高QOS发送视频，而数据/命令可能会出现延迟。我从来没有真正使用QOS，所以我不知道问题出在哪里，但它可能会影响您对WCF的决定（无论是有利的还是消极的）。

您可以将服务器托管在自己的进程或IIS。如果你自己托管它，那么你可以用自己的方式做事。我相信WCF和IIS是好朋友，所以如果你在想IIS，那么WCF可能会让生活变得更容易。如果您通过自己的主机选择IIS（或任何已建立的Web服务器），则可以利用其基础架构 - 可扩展性，可靠性，加密等等。缺点是您可能会被锁定在该服务器上，但实际上这可能不是问题。

根据您的环境，您可能可以混合搭配各种技术和功能。例如，我们有一个系统听起来与您的模糊不清，我们选择：客户端中的普通套接字;服务器中的普通套接字，但可以选择在Apache中托管服务器;一个自定义XML库，它只是我们需要的;嵌入式OpenSSL; COM是系统的核心，但依赖于.NET。特别是，我们在第一个原型中使用了SOAP，因为它的消息传递和RPC与我们的设计完美匹配，但是发现它增加了太多的复杂性，并用我们自己的协议取而代之。

如果您有时间，那么我建议您在WCF中构建一个快速原型并查看您的想法。希望它能解决问题，但如果没有的话，不要害怕丢弃它。主要原则是尽可能高效地为客户提供最大的商业价值，这通常意味着您应该将精力花在应用程序领域而不是基础架构上。但同时不要忽略诸如性能，可靠性，可伸缩性，维护性，可扩展性等次要原则。