命名管道或TCP用于客户端/服务器通信

Question

我的应用程序支持同一服务器进程的多个实例 (Windows服务)，就像 SQL Server 一样。

客户端/服务器通信将仅在同一网络中进行。

我可以使用 TCP，但这样我必须为每个服务器实例配置单独的 IP 端口。然而，我可以简单地使用命名管道，这样我就不必考虑端口号，只需使用服务器实例的名称即可。

客户端/服务器通信不会非常频繁和/或数据量很大。它是一种 ERP 应用程序，平均每30秒只会通信一次。

此外，我希望防止任何客户端/服务器通信超出网络 (内部网)。

在这里做一个明智的选择是什么?

更新：客户端和服务器都是使用 .NET 4 编写的，没有第三方客户端能够使用服务器。

- user564548

---

选择名称的便利性不应成为首选命名管道的原因。客户端如何找到管道的名称？ - Miserable Variable

为什么不创建一个抽象的传输框架，允许使用命名管道或TCP？SQL Server正是这样做的。 - Jonathan Dickinson

@Jonathan：或者使用现有的像WCF（它是.NET的一部分）这样的。 - Stephan

Answer 1

我在我的几个个人项目中使用 .net 4.0 命名管道(System.IO.Pipes)，它们非常容易使用。你可以在整个内部网络中使用命名管道，而且性能非常好，所以我的个人建议是选择命名管道。

此外，.net 4.0 命名管道客户端利用底层的 WinAPI，因此您还可以从您的 .NET 应用程序与本地应用程序通信。

- Teoman Soygul

Answer 2

这将取决于客户端技术。

如果服务器和客户端都是完整的.NET Framework，则命名管道听起来不错。

但是，如果某些客户端可能是任何不是.NET Framework的东西（Web客户端、Silverlight或类似的东西），那么命名管道将会带来过多的痛苦，因为并非所有客户端技术都具有任何网络连接或开箱即用的API来执行您所想要的操作。

总结：

- 如果客户端和服务器都使用.NET Framework，并且始终如此，并且没有计划实现与此场景不同的任何内容，请使用命名管道。 - 如果您想确保您的服务器可以与任何类型的客户端技术通信，请使用TCP。

无论如何，您是否打算使用WCF？也许使用TCP或命名管道只是一种配置方法。请查看此MSDN文章：

• http://msdn.microsoft.com/en-us/library/ms733769.aspx

- Matías Fidemraizer

---

我已更新我的问题。客户端和服务器都是用.NET 4编写的。 - user564548

我的回答仍然有效 :) 但是无论如何，还是谢谢你更加具体地说明了。 - Matías Fidemraizer