在 Mac OS X 上进行进程间通信的最佳方式

Question

我正在考虑在 Mac 上构建一个带有后端守护进程的 Cocoa 应用程序（可能实际上只是一个无头的 Cocoa 应用程序），以及 0 个或多个本地运行的“客户端”应用程序（尽管如果可能的话我会也喜欢支持远程客户端；远程客户端只能是其他 Mac 或 iPhone OS 设备）。

所传达的数据将相当琐碎，大部分只是文本和命令（我想无论如何都可以表示为文本），也许偶尔还有小文件（可能是图像）。

我已经研究了几种执行此操作的方法，但我不确定哪种方法最适合当前的任务。我考虑过的事情：

• 读取和写入文件（……是的），非常基本，但可扩展性不太好。
• 纯套接字（我没有使用套接字的经验，但我似乎认为我可以使用它们在本地和通过网络发送数据。虽然如果一切都在 Cocoa 中进行似乎很麻烦
• 分布式对象：对于这样的任务来说似乎相当不优雅
• NSConnection: ：我真的不知道这个类到底做了什么，但我在一些 IPC 搜索结果中读到过它

我确信我遗漏了一些东西，但我惊讶地发现缺乏关于这个主题的资源。

Answer 1

我目前正在研究同样的问题。对我来说，稍后添加 Windows 客户端的可能性会让情况变得更加复杂；就你而言，答案似乎更简单。

关于您考虑过的选项：

1. 控制文件： 虽然可以通过控制文件进行通信，但您必须记住，文件需要通过网络文件系统在所涉及的计算机之间进行通信。因此，网络文件系统充当实际网络基础设施的抽象，但不提供网络通常具有的全部功能和灵活性。 执行： 实际上，每对客户端/服务器至少需要两个文件：服务器用于向客户端发送请求的文件和用于响应的文件。如果每个进程都可以双向通信，则需要复制此内容。此外，客户端和服务器都在“拉”的基础上工作，即，它们需要经常重新访问控制文件并查看是否已交付新内容。

   该解决方案的优点是最大限度地减少了学习新技术的需要。最大的缺点是对程序逻辑要求很高；很多事情需要你处理（这些文件会被写成一个整体，还是可能会发生任何一方拾取不一致的文件？应该多久进行一次检查？我是否需要担心文件系统，例如缓存等？我可以稍后添加加密，而不需要尝试程序代码之外的东西吗？...)

   如果可移植性是一个问题（据我从你的问题中了解到，情况并非如此），那么这个解决方案将很容易移植到不同的系统，甚至不同的编程语言。但是，我不知道iPhone OS有任何网络文件系统，但我对此并不熟悉。

2. 插座： 编程接口肯定是不同的；根据您在套接字编程方面的经验，这可能意味着您需要更多的工作来先学习它，然后再调试它。 执行: ：实际上，您将需要与以前类似的逻辑，即客户端和服务器通过网络进行通信。这种方法的一个明显优点是进程可以在“推送”的基础上工作，即它们可以侦听套接字直到消息到达，这优于定期检查控制文件。网络损坏和不一致也不是您所关心的。此外，您（可能）对建立连接的方式有更多的控制，而不是依赖于程序控制之外的事物（同样，如果您决定稍后添加加密，这一点很重要）。

   这样做的好处是，很多事情都可以从你的肩膀上卸下来，这些事情会困扰 1 中的实现。缺点是您仍然需要大幅更改程序逻辑，以确保发送和接收正确的信息（文件类型等）。

   根据我的经验，可移植性（即，易于转换到不同的系统甚至编程语言）非常好，因为任何与 POSIX 远程兼容的东西都可以工作。

   [编辑： 特别是，一旦您传递二进制数字节序就成为一个问题，您必须手动处理这个问题 - 这是我上面提到的“正确信息”问题的常见（！）特殊情况。它会咬你，例如当您有一台 PowerPC 与一台 Intel Mac 通信时。这种特殊情况随着解 3.+4 的出现而消失。所有其他“正确信息”问题将一起解决。]

3. +4. 分布式对象： 这 NSProxy 类簇用于实现分布式对象。 NSConnection 负责建立远程连接作为发送信息的先决条件，因此一旦您了解了如何使用该系统，您也就了解了分布式对象。;^)

   这个想法是，您的高级程序逻辑不需要更改（即，您的对象通过消息进行通信并接收结果，并且消息和返回类型与您在本地实现中所习惯的相同），而无需更改关心网络基础设施的细节。嗯，至少在理论上是这样。 执行： 我现在也在做这方面的工作，所以理解还很有限。据我了解，您确实需要设置一定的结构，即您仍然必须决定哪些进程（本地和/或远程）可以接收哪些消息；这是什么 NSConnection 做。至此，你就隐式定义了一个客户端/服务器架构，但是你不需要担心2中提到的问题。

   Gnustep 项目服务器上有两个明确示例的介绍；它说明了该技术的工作原理，并且是进行实验的良好起点：http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_7.html

   不幸的是，缺点是完全丧失与其他系统的兼容性（尽管您仍然可以使用您提到的 Mac 和 iPhone/iPad 的设置），并且丧失对其他语言的可移植性。Gnustep 与 Objective-C 充其量是代码兼容，但无法通信 之间 Gnustep 和 Cocoa，请参阅我对问题 2 的编辑： Mac OS X 上的 CORBA (Cocoa)

   [编辑： 我刚刚又发现了一条我不知道的信息。虽然我已经检查过了 NSProxy iPhone上可用，我没有检查分布式对象机制的其他部分是否可用。根据这个链接： http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships- Between-nsconnection-nsinputstream-nsoutputstream-etc.html （在页面中搜索短语“iPhone OS”）它们不是。如果您此时需要使用 iPhone/iPad，则此解决方案将被排除在外。]

总而言之，一方面学习（以及实现和调试）新技术的努力与另一方面手工编码较低级别的通信逻辑之间存在权衡。虽然分布式对象方法承担了您的大部分负担，并且在程序逻辑中引起的变化最小，但它是最难学习的，而且（不幸的是）可移植性也最差。

Answer 2

免责声明： 分布式对象是 在 iPhone 上不可用.

---

为什么你会发现 分布式对象 不优雅？他们在这里听起来很匹配：

• 基本类型和 Objective-C 类的透明编组
• 客户端是本地还是远程并不重要
• 基于 Cocoa 的应用程序不需要太多额外的工作

文档可能听起来比实际需要做更多的工作，但您基本上要做的就是干净地使用协议并导出或分别连接到服务器根对象。
在给定的场景中，其余的事情应该在幕后自动发生。

Answer 3

我们正在使用 托莫网络公司 它工作正常并且设置速度很快。基本上，它允许您在本地网络中发送符合 NSCoding 的对象，但如果客户端和服务器位于同一台计算机上，当然也可以工作。作为基础类的包装器，它负责配对、重新连接等。