我有一个场景需要在两个客户端之间发送一系列数据。
数据包括序列化XML，其中包含其他客户端需要响应的命令。
我还需要通过网络发送图像，因为我需要以视频/音频聊天的形式提供聊天功能。
我想为两者提供单一的通信媒介，因为消息/命令的数量可能很少。
WCF或套接字？
答案 0 :(得分：4)
WCF是用于构建面向服务的应用程序的API。我不认为视频/语音聊天就是这种应用。
首先，您需要为此类应用程序提供哪些传输功能？我对语音/视频传输的了解很差，但我希望：
因此，通过简单描述这三个期望，我已经看到了问题。 WCF内置Net.Tcp绑定does not allow duplex communication and streaming together。还要注意，通过WCF进行Net.tcp通信的性能比普通的socket通信要糟糕得多。这是因为WCF简化了很多事情，但这些简化和概括减慢了处理速度。
同样基于选定的算法this可能是个问题。
Here您可以在Silverlight 4中找到一些视频聊天的描述.Silverlight允许WCF和net.tcp绑定，但仍然在套接字上开发通信。
Here您可以找到广泛使用的IP语音协议的描述 - 用于数据传输的RTP和用于协调和QoS的RTCP。这些协议也用于视频传输。通过谷歌搜索我找到了implementation的.NET（我不知道实现有多好，我只是用谷歌...）
答案 1 :(得分：3)
以下是我想到的一些事情：
如果您预计有几种不同类型的客户端连接到您的服务器，则WCF可能很有用。也许将来你可能想让其他人写客户，或多或少独立于你。另一方面，如果它是一个封闭的系统，那么您可能更喜欢编写自己的套接字代码。
WCF为您提供更高级别的抽象，因此您可以更快地编写系统。特别是，XML编码和会话管理等内容并不是应用程序域的一部分，因此您不希望花费太多时间来处理它们。但是更高的抽象通常涉及性能成本，因为抽象层比任何一个应用程序需要的更通用。使用普通套接字，您可以根据自己的需要定制系统，这可能会带来更高的性能（代价是更加繁琐的开发和错误修复。）
您可能希望在不同的流中发送数据/命令和视频。据推测，数据/命令必须通过可靠的传输方式发送，但视频可能会遭受一些损失。或者视频应该以高QOS发送，而数据/命令可能会遭受延迟。我从来没有真正使用过QOS，所以我不知道这里有什么问题，但它可能会影响你对WCF的决定（无论是有利还是消极）。
您可以在自己的进程或IIS中托管服务器。如果您自己主持，那么您可以按照自己的方式做事。我相信WCF和IIS是好朋友，所以如果你在想IIS，那么WCF可能会让生活变得更轻松。如果您在自己的主机上选择IIS（或任何已建立的Web服务器），则可以利用其基础结构 - 可伸缩性，可靠性，加密等。缺点是您可能会被锁定在该服务器上，但这在实践中可能不是问题。
根据您的环境，您可以混合搭配各种技术和功能。例如，我们有一个听起来与你的系统模糊相似的系统，我们选择了：客户端的普通套接字;服务器中的普通套接字，但可以选择在Apache中托管服务器;一个自定义的XML库，可以满足我们的需求;嵌入式OpenSSL; COM是系统的核心，但依赖于.NET。特别是，我们在第一个原型中使用了SOAP，因为它的消息传递和RPC完全匹配我们的设计，但发现它增加了太多的复杂性并用我们自己的协议取而代之。
如果你有时间，那么我建议你在WCF中构建一个快速原型并看看你的想法。希望它成功，但如果不这样做，不要害怕抛弃它。主要原则是尽可能高效地为您的客户提供最大的业务价值，这通常意味着您应该在应用程序域而不是基础架构上花费精力。但同时不要忽视性能，可靠性，可伸缩性，维护，可扩展性等辅助原则。
答案 2 :(得分：0)
WCF 或套接字???这些不是替代方案：WCF包括用于TCP / IP通信的NetTcpBinding和NetPeerTcpBinding。
如果您的客户端都是Windows，则应使用WCF。