在Mac OS X上进行进程间通信的最佳方法 [英] Best way to do interprocess communication on Mac OS X

问题描述

我正在寻找一个Cocoa应用程序在Mac上的后端守护进程（真的只是一个几乎无头的Cocoa应用程序），以及0个或更多客户端应用程序本地运行（尽管如果可能的话我也想支持远程客户端;远程客户端只会是其他Mac或iPhone操作系统设备）。

正在传输的数据将是相当微不足道，大部分只是文本和命令（我猜它可以表示为文本），也许偶尔的小文件（一个图像可能）。

我看过几个方法做这个，但我不知道哪个是最好的手头的任务。我考虑的事情：

• 读取和写入文件（...是），非常基本，但不是非常可扩展。
  
• 纯套接字（我没有经验的套接字，但我似乎认为我可以使用它们发送数据在本地和通过网络。虽然这似乎很麻烦，如果做一切Cocoa


• 分布式对象：对于像这样的任务看起来相当不起眼


• NSConnection ：我真的不知道这是什么类甚至，但我已经在一些IPC搜索结果中读取它

我确定有些东西我缺少，但我很惊讶地发现这个主题缺乏资源。

解决方案

我目前正在研究同样的问题。

关于您考虑的选项：

1. 控制文件：虽然可以通过控制文件进行通信，但必须记住，需要通过所涉及的机器之间的网络文件系统进行通信。因此，网络文件系统作为实际网络基础设施的抽象，但不提供网络通常具有的全部功率和灵活性。 实现：实际上，您将需要为每对客户端/服务器至少有两个文件：服务器用于向客户端发送请求的文件和用于响应的文件。如果每个进程可以通信两种方式，您需要复制此。此外，客户端和服务器都在拉的基础上工作，即，他们需要频繁地访问控制文件并查看是否已经传送了新的内容。

   
   
   

   这个解决方案的优点是它最小化了学习新技术的需要。最大的缺点是对程序逻辑有很大的要求;很多事情需要被你照顾（文件是否会被写成一个整体，或者是否任何一方挑选不一致的文件？应该多久检查一次？我需要担心文件系统，像缓存等等？我可以添加加密以后不用在我的程序代码之外的事情吗？...）

   
   
   

   如果可移植性是一个问题因为我的理解从你的问题不是这样），那么这个解决方案将很容易移植到不同的系统，甚至不同的编程语言。但是，我不知道用于iPhone操作系统的任何网络文件ystem，但我不熟悉这个。




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

   
   
   

   这样做的好处是，很多东西都会从你的肩膀上脱下来，这会让你在1中的实现变得麻烦。缺点是你仍然需要大幅度改变你的程序逻辑，以确保你发送和接收正确的信息（文件类型等）。

   
   
   

   在我的经验中，可移植性（即易于转换到不同的系统甚至编程语言）

   [编辑：特别是，一旦你传送二进制数字，endianess就成为一个问题，你必须采取手动处理这个问题 - 这是上面提到的正确信息问题的常见（！）特殊情况。它会咬你。当你有一个PowerPC与Intel Mac通话。这个特殊情况与解决方案3. + 4消失。一起将所有其他正确的信息问题。]




3. +4。 分布式对象： NSProxy 类集群用于实现分布式对象。 NSConnection 负责设置远程连接作为发送信息的先决条件，因此一旦您了解如何使用此系统，您还可以了解分布式对象。 ; ^）

   
   
   

   这个想法是，你的高级程序逻辑不需要改变（即你的对象通过消息通信，接收结果和消息返回类型与您在本地实现中使用的类型相同），而不必担心网络基础架构的特性。好吧，至少在理论上。实施： 我现在也在做这个工作，所以我的理解仍然有限。据我所知，你需要设置一个特定的结构，即你仍然必须决定哪些进程（本地和/或远程）可以接收哪些消息;这是 NSConnection 的作用。此时，您隐式定义了客户端/服务器体系结构，但您不需要担心2中提到的问题。

   
   
   

   有两个显式示例在Gnustep项目服务器;它说明了技术如何工作，是实验的一个良好的起点：$ b​​ $ b http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_7.html

   
   
   

   不幸的是，缺点是完全失去兼容性（虽然你仍然会完美地与您提到的Macs和iPhone / iPad的设置）与其他系统和其他语言的可移植性损失。 Gnustep与Objective-C是最好的代码兼容，但是没有办法在 Gnustep和Cocoa之间进行通信，请参阅我对第2个问题的编辑： Mac OS X上的CORBA（可可）

   
   
   

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

是在一方面学习（以及实现和调试）新技术和另一方面手工编码较低级通信逻辑的努力之间的折衷。虽然分布式对象方法占用了大部分的负载，并且程序逻辑中的变化最小，但是它是最难学习的，也是最不便携的。

I'm looking at building a Cocoa application on the Mac with a back-end daemon process (really just a mostly-headless Cocoa app, probably), along with 0 or more "client" applications running locally (although if possible I'd like to support remote clients as well; the remote clients would only ever be other Macs or iPhone OS devices).

The data being communicated will be fairly trivial, mostly just text and commands (which I guess can be represented as text anyway), and maybe the occasional small file (an image possibly).

I've looked at a few methods for doing this but I'm not sure which is "best" for the task at hand. Things I've considered:

• Reading and writing to a file (…yes), very basic but not very scalable.
• Pure sockets (I have no experience with sockets but I seem to think I can use them to send data locally and over a network. Though it seems cumbersome if doing everything in Cocoa
• Distributed Objects: seems rather inelegant for a task like this
• NSConnection: I can't really figure out what this class even does, but I've read of it in some IPC search results

I'm sure there are things I'm missing, but I was surprised to find a lack of resources on this topic.

解决方案

I am currently looking into the same questions. For me the possibility of adding Windows clients later makes the situation more complicated; in your case the answer seems to be simpler.

About the options you have considered:

1. Control files: While it is possible to communicate via control files, you have to keep in mind that the files need to be communicated via a network file system among the machines involved. So the network file system serves as an abstraction of the actual network infrastructure, but does not offer the full power and flexibility the network normally has. Implementation: Practically, you will need to have at least two files for each pair of client/servers: a file the server uses to send a request to the client(s) and a file for the responses. If each process can communicate both ways, you need to duplicate this. Furthermore, both the client(s) and the server(s) work on a "pull" basis, i.e., they need to revisit the control files frequently and see if something new has been delivered.

   The advantage of this solution is that it minimizes the need for learning new techniques. The big disadvantage is that it has huge demands on the program logic; a lot of things need to be taken care of by you (Will the files be written in one piece or can it happen that any party picks up inconsistent files? How frequently should checks be implemented? Do I need to worry about the file system, like caching, etc? Can I add encryption later without toying around with things outside of my program code? ...)

   If portability was an issue (which, as far as I understood from your question is not the case) then this solution would be easy to port to different systems and even different programming languages. However, I don't know of any network files ystem for iPhone OS, but I am not familiar with this.

2. Sockets: The programming interface is certainly different; depending on your experience with socket programming it may mean that you have more work learning it first and debugging it later. Implementation: Practically, you will need a similar logic as before, i.e., client(s) and server(s) communicating via the network. A definite plus of this approach is that the processes can work on a "push" basis, i.e., they can listen on a socket until a message arrives which is superior to checking control files regularly. Network corruption and inconsistencies are also not your concern. Furthermore, you (may) have more control over the way the connections are established rather than relying on things outside of your program's control (again, this is important if you decide to add encryption later on).

   The advantage is that a lot of things are taken off your shoulders that would bother an implementation in 1. The disadvantage is that you still need to change your program logic substantially in order to make sure that you send and receive the correct information (file types etc.).

   In my experience portability (i.e., ease of transitioning to different systems and even programming languages) is very good since anything even remotely compatible to POSIX works.

   [EDIT: In particular, as soon as you communicate binary numbers endianess becomes an issue and you have to take care of this problem manually - this is a common (!) special case of the "correct information" issue I mentioned above. It will bite you e.g. when you have a PowerPC talking to an Intel Mac. This special case disappears with the solution 3.+4. together will all of the other "correct information" issues.]

3. +4. Distributed objects: The NSProxy class cluster is used to implement distributed objects. NSConnection is responsible for setting up remote connections as a prerequisite for sending information around, so once you understand how to use this system, you also understand distributed objects. ;^)

   The idea is that your high-level program logic does not need to be changed (i.e., your objects communicate via messages and receive results and the messages together with the return types are identical to what you are used to from your local implementation) without having to bother about the particulars of the network infrastructure. Well, at least in theory. Implementation: I am also working on this right now, so my understanding is still limited. As far as I understand, you do need to setup a certain structure, i.e., you still have to decide which processes (local and/or remote) can receive which messages; this is what NSConnection does. At this point, you implicitly define a client/server architecture, but you do not need to worry about the problems mentioned in 2.

   There is an introduction with two explicit examples at the Gnustep project server; it illustrates how the technology works and is a good starting point for experimenting: http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_7.html

   Unfortunately, the disadvantages are a total loss of compatibility (although you will still do fine with the setup you mentioned of Macs and iPhone/iPad only) with other systems and loss of portability to other languages. Gnustep with Objective-C is at best code-compatible, but there is no way to communicate between Gnustep and Cocoa, see my edit to question number 2 here: CORBA on Mac OS X (Cocoa)

   [EDIT: I just came across another piece of information that I was unaware of. While I have checked that NSProxy is available on the iPhone, I did not check whether the other parts of the distributed objects mechanism are. According to this link: http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships-between-nsconnection-nsinputstream-nsoutputstream-etc.html (search the page for the phrase "iPhone OS") they are not. This would exclude this solution if you demand to use iPhone/iPad at this moment.]

So to conclude, there is a trade-off between effort of learning (and implementing and debugging) new technologies on the one hand and hand-coding lower-level communication logic on the other. While the distributed object approach takes most load of your shoulders and incurs the smallest changes in program logic, it is the hardest to learn and also (unfortunately) the least portable.

这篇关于在Mac OS X上进行进程间通信的最佳方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！