C#套接字与管道 [英] C# Sockets vs Pipes

问题描述

当前，我正在Windows上处理多进程桌面应用程序.该应用程序将是一个收缩包装的应用程序，将被部署在世界各地的客户端计算机上.虽然我们可以为机器提供广泛的规格-例如装有.Net 4.0 CF的Windows XP SP3，我们将无法对其进行控制，并且我们对其配置也不能太具体-例如我们无法指定机器必须具有支持cuda 1.4的图形处理器等.

Currently I am working on a multi-process desktop application on Windows. This application will be a shrink wrapped application which will be deployed on client machines across the world. While we can have broad specifications for the machines - e.g. Windows XP SP3 with .Net 4.0 CF, we wont have control over them and we cant be too specific on their configuration - e.g. we cannot specify the machine must have a cuda 1.4 capable graphic processor etc.

其中一些进程是托管的(.Net 4.0)，而其他进程是不受托管的(C ++ Win32).流程需要共享数据.到目前为止，我评估过的选项是

Some of these processes are managed (.Net 4.0) and others are unmanaged (C++ Win32). The processes need to share data. The options I have evaluated to date are

• TCP套接字
• 命名管道

管道的性能似乎要好一些，但是对于我们的需求-两者的性能都是可以接受的.套接字在将来为我们提供了跨越机器(和操作系统-我们最终将要支持非Microsoft操作系统)边界的灵活性，因此我们更喜欢使用套接字.

Pipes seem to perform a little better, but for our needs - performance from both are acceptable. And sockets give us the flexibility of crossing machine (and operating systems - we would like to support non-Microsoft OSes eventually) boundaries in the future hence our preference for going with sockets.

但是-我主要担心的是-如果我们使用Tcp套接字-我们是否可能会遇到防火墙问题?是否还有其他人部署了使用TCP进行IPC和遇到问题的桌面应用程序/程序?如果是这样-哪种?

However - my major concern is this - If we use Tcp sockets - are we likely to run into issues with firewalls? Has anyone else deployed desktop applications / programs that use TCP for IPC and experienced issues? If so - what kind?

我知道这是一个相当开放的问题，我将很高兴对此重新表述.但是我真的很想知道我们可能会遇到什么样的潜在问题.

I know this is a fairly open ended question and I will be glad to rephrase. But I would really like to know what kind of potential problems we are likely to run into.

编辑:要多加一点点-我们仅在传递一些POD，整数，浮点数和字符串.我们建立了一个抽象层，提供2个范式-请求/响应和订阅.传输层已被抽象化，目前我们有两种实现方式-基于管道和基于TCP.

edit: To throw a little more light - we are only transporting a few PODs, ints, floats and strings. We have built a layer of abstraction that offers 2 paradigms - a request/response and subscription . The transport layer has been abstracted away and currently we have two implementations - pipe based and TCP based.

推荐答案

在快速的LAN上，管道的性能通常更好，但是在速度较慢的网络或WAN上，TCP的性能通常更好.请参阅下面的msdn点.

Performance of pipes is often better on a fast LAN but TCP is often better on slower networks or WANs. See msdn points below.

TPC也更具可配置性.关于防火墙，它们使您可以打开/关闭通信端口.如果这不是一个选择或考虑的问题，则可以选择使用http(REST/json，Web服务，xml rpc等)，但是您必须考虑是否可以接受http开销.确保使用真实世界的数据集进行尝试(在测试中传递琐碎的数据会使开销看起来不合理，这对于真实世界的数据集来说是非常合理的).

TPC is also more configurable. Concerning firewalls, they allow you to open/close communication ports. If that's not an option or a concern, an alternative would be http (REST/json, web service, xml rpc, etc...) but you have to consider if the http overhead is acceptable. Make sure you try it with real world datasets (passing trivial data in a test makes the overhead seem unreasonable, which would be very reasonable with a real world data set).

来自 msdn :

在快速局域网(LAN)环境中，传输控制 协议/Internet协议(TCP/IP)套接字和命名管道客户端 在性能方面具有可比性.但是，性能 TCP/IP套接字和命名管道客户端之间的差异变为 在较慢的网络(例如跨广域网)中显而易见 (WAN)或拨号网络.这是因为不同的方式 进程间通信(IPC)机制在同级之间进行通信.

In a fast local area network (LAN) environment, Transmission Control Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are comparable in terms of performance. However, the performance difference between the TCP/IP Sockets and Named Pipes clients becomes apparent with slower networks, such as across wide area networks (WANs) or dial-up networks. This is because of the different ways the interprocess communication (IPC) mechanisms communicate between peers.

对于命名管道，网络通信通常更多 交互的.一个对等方直到另一个对等方要求时才发送数据 使用读取命令.网络读取通常涉及一系列 在开始读取数据之前，先查看命名管道消息.这些可以 在慢速的网络中成本很高，并导致过多的网络流量， 反过来会影响其他网络客户端.

For named pipes, network communications are typically more interactive. A peer does not send data until another peer asks for it using a read command. A network read typically involves a series of peek named pipes messages before it begins to read the data. These can be very costly in a slow network and cause excessive network traffic, which in turn affects other network clients.

弄清您是否在谈论本地管道也很重要 或网络管道.如果服务器应用程序在本地运行 运行Microsoft®SQL Server™2000实例(本地)的计算机 命名管道协议是一个选项.本地命名管道在内核中运行 模式，速度非常快.

It is also important to clarify if you are talking about local pipes or network pipes. If the server application is running locally on the computer running an instance of Microsoft® SQL Server™ 2000, the local Named Pipes protocol is an option. Local named pipes runs in kernel mode and is extremely fast.

对于TCP/IP套接字，数据传输更加简化并且具有 更少的开销.数据传输也可以利用TCP/IP 套接字性能增强机制，例如开窗，延迟 确认等等，这在缓慢的情况下会非常有益 网络.根据应用程序的类型，这种性能 差异可能很大.

For TCP/IP Sockets, data transmissions are more streamlined and have less overhead. Data transmissions can also take advantage of TCP/IP Sockets performance enhancement mechanisms such as windowing, delayed acknowledgements, and so on, which can be very beneficial in a slow network. Depending on the type of applications, such performance differences can be significant.

TCP/IP套接字还支持积压队列，该队列可以提供 与命名管道相比，有限的平滑效果可能会导致管道 尝试连接到SQL Server时出现繁忙错误.

TCP/IP Sockets also support a backlog queue, which can provide a limited smoothing effect compared to named pipes that may lead to pipe busy errors when you are attempting to connect to SQL Server.

>通常，在速度较慢的LAN，WAN或拨号网络中，首选使用套接字 网络，而网络速度快时，命名管道可能是更好的选择 这不是问题，因为它提供了更多的功能，易用性以及 配置选项.

> In general, sockets are preferred in a slow LAN, WAN, or dial-up network, whereas named pipes can be a better choice when network speed is not the issue, as it offers more functionality, ease of use, and configuration options.

有关TCP/IP的更多信息，请参见Microsoft WindowsNT®. 文档.

For more information about TCP/IP, see the Microsoft Windows NT® documentation.

这篇关于C#套接字与管道的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！