30

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

正在传达的数据将是相当微不足道的，主要是文本和命令（我猜无论如何都可以表示为文本），也许偶尔会有小文件（可能是图像）。

我已经研究了一些方法来做到这一点，但我不确定哪种方法最适合手头的任务。我考虑过的事情：

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

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

4

3 回答 3

16

我目前正在研究同样的问题。对我来说，以后添加 Windows 客户端的可能性会使情况变得更加复杂。在您的情况下，答案似乎更简单。

关于您考虑过的选项：

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

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

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

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

    优点是您无需承担很多会影响 1 中的实现的事情。缺点是您仍然需要大幅更改程序逻辑以确保发送和接收正确的信息（文件类型ETC。）。

    根据我的经验，可移植性（即易于转换到不同的系统甚至编程语言）非常好，因为任何与 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 的设置）以及失去对其他语言的可移植性。带有 Objective-C 的 Gnustep 充其量是代码兼容的，但是Gnustep 和 Cocoa之间无法进行通信，请参阅我对问题 2 的编辑：Mac OS X (Cocoa) 上的 CORBA

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

因此，总而言之，一方面是学习（以及实施和调试）新技术的努力，另一方面是手工编码较低级别的通信逻辑。虽然分布式对象方法承担了你的大部分负担，并在程序逻辑中产生了最小的变化，但它是最难学习的，而且（不幸的是）最不便携。

于 2010-05-23T19:20:18.320 回答
14

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

为什么你觉得分布式对象不优雅？他们在这里听起来很合适：

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

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

于 2010-05-17T03:11:33.683 回答
7

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

于 2010-05-26T14:25:41.520 回答