If you're unsure about your exact requirements at the moment, try to think of a simple interface that you can code to, that any IPC implementation (be it temporary files, TCP/IP or whatever) needs to support. You can then choose a particular IPC flavour (I would start with whatever's easiest and/or easiest to debug -- probably temporary files) and implement the interface using that. If that turns out to be too slow, implement the interface using e.g. TCP/IP. Actually implementing the interface does not involve much work as you will essentially just be forwarding calls to some existing library.
The point is that you have a high-level task to perform ("transmit data from program A to program B") which is more or less independent of the details of how it is performed. By establishing an interface and coding to it, you isolate the main program from changes in the event that you need to change the implementation.
Note that you don't need to use any heavyweight Perl language mechanisms to capitalise on the idea of having an interface. You could simply have e.g. 3 different packages (for temp files, TCP/IP, Unix domain sockets), each of which exports the same set of methods. Choosing which implementation you want to use in your main program amounts to choosing which module to use.
Temporary files (and related things, like a shared memory region), are probably a bad bet. If you ever want to run your server on one machine and your clients on another, you will need to rewrite your application. If you pick any of the other options, at least the semantics are the essentially the same, if you need to switch between them at a later date.
My only real advice, though, is to not write this yourself. On the server side, you should use POE (or Coro, etc.), rather than doing select on the socket yourself. Also, if your interface is going to be RPC-ish, use something like JSON-RPC-Common/ from the CPAN.
Finally, there is IPC::PubSub, which might work for you.
Temporary files have other problems besides that. I think Internet socks are really the best choice. They are well documented, and as you say, scalable and portable. Even if that is not a core requirement, you get it nearly for free. Sockets are pretty easy to deal with, again there is copious amounts of documentation. You can build out your data sharing mechanism and protocol out in a library and never have to look at it again!
UNIX domain sockets are portable across unices. It's no less portable than pipes. It's also more efficient than IP sockets.
Anyway, you missed a few options, shared memory for example. Some would add databases to that list but I'd say that's a rather heavyweight solution.
Message queues would also be a possibility, though you'd have to change a kernel option for it to handle such large messages. Otherwise, they have an ideal interface for a lot of things, and IMHO they are greatly underused.
I generally agree though that using an existing solution is better than building somethings of your own. I don't know the specifics of your problem, but I'd suggest you'd check out the IPC section of CPAN
There are so many different options because most of them are better for some particular case, but you haven't really given any information that would identify your case.
Are readers/writers in a one-to-one relationship, or something more more complicated? What do you want to happen to the writer if the reader is no longer there or busy? And vice versa? What other information do you have about your desired usage?
For "interactive" requests (holding the connection open while waiting for a response (asynchronously or not): HTTP + JSON. JSON::XS is insanely fast. Everyone and everything can speak HTTP and it's easy to load balance, debug, ...
For queued requests ("please do this, thanks!"): Beanstalkd and Beanstalk::Client. Serialize the requests in the beanstalk queue with JSON.
Thrift might also be worth looking into depending on your application.
发布评论
评论（6）
如果您目前不确定自己的确切要求，请尝试考虑一个可以编码的简单接口，任何 IPC 实现（无论是临时文件、TCP/IP 或其他）都需要该接口支持。 然后，您可以选择特定的 IPC 风格（我会从最简单和/或最容易调试的内容开始——可能是临时文件）并使用它来实现接口。 如果结果发现太慢，请使用 TCP/IP 等实现接口。 实际上实现该接口并不涉及太多工作，因为您本质上只是将调用转发到一些现有的库。
关键是您要执行一项高级任务（“将数据从程序 A 传输到程序 B”），该任务或多或少独立于其执行方式的细节。 通过建立接口并对其进行编码，您可以在需要更改实现时将主程序与更改隔离。
请注意，您不需要使用任何重量级 Perl 语言机制来利用接口的想法。 您可以简单地拥有例如 3 个不同的包（用于临时文件、TCP/IP、Unix 域套接字），每个包都导出相同的方法集。 选择要在主程序中使用哪个实现相当于选择要
使用的模块。If you're unsure about your exact requirements at the moment, try to think of a simple interface that you can code to, that any IPC implementation (be it temporary files, TCP/IP or whatever) needs to support. You can then choose a particular IPC flavour (I would start with whatever's easiest and/or easiest to debug -- probably temporary files) and implement the interface using that. If that turns out to be too slow, implement the interface using e.g. TCP/IP. Actually implementing the interface does not involve much work as you will essentially just be forwarding calls to some existing library.
The point is that you have a high-level task to perform ("transmit data from program A to program B") which is more or less independent of the details of how it is performed. By establishing an interface and coding to it, you isolate the main program from changes in the event that you need to change the implementation.
Note that you don't need to use any heavyweight Perl language mechanisms to capitalise on the idea of having an interface. You could simply have e.g. 3 different packages (for temp files, TCP/IP, Unix domain sockets), each of which exports the same set of methods. Choosing which implementation you want to use in your main program amounts to choosing which module to
use.临时文件（以及相关的东西，比如共享内存区域）可能是一个糟糕的选择。 如果您想在一台计算机上运行服务器并在另一台计算机上运行客户端，则需要重写您的应用程序。 如果您选择任何其他选项，至少语义本质上是相同的，如果您以后需要在它们之间切换的话。
不过，我唯一真正的建议是不要自己写这个。 在服务器端，您应该使用POE（或Coro等），而不是自己在套接字上执行
select。 另外，如果您的界面将是 RPC 式的，请使用类似 的内容来自 CPAN 的 JSON-RPC-Common/。最后，还有 IPC::PubSub，它可能适合您。
Temporary files (and related things, like a shared memory region), are probably a bad bet. If you ever want to run your server on one machine and your clients on another, you will need to rewrite your application. If you pick any of the other options, at least the semantics are the essentially the same, if you need to switch between them at a later date.
My only real advice, though, is to not write this yourself. On the server side, you should use POE (or Coro, etc.), rather than doing
selecton the socket yourself. Also, if your interface is going to be RPC-ish, use something like JSON-RPC-Common/ from the CPAN.Finally, there is IPC::PubSub, which might work for you.
除此之外，临时文件还有其他问题。 我觉得网络袜确实是最好的选择。 它们有详细的文档记录，并且正如您所说，可扩展且可移植。 即使这不是核心要求，您也几乎免费获得它。 套接字非常容易处理，同样有大量的文档。 您可以在库中构建数据共享机制和协议，而无需再次查看它！
Temporary files have other problems besides that. I think Internet socks are really the best choice. They are well documented, and as you say, scalable and portable. Even if that is not a core requirement, you get it nearly for free. Sockets are pretty easy to deal with, again there is copious amounts of documentation. You can build out your data sharing mechanism and protocol out in a library and never have to look at it again!
UNIX 域套接字可跨 unice 移植。 它的便携性并不比管道差。 它也比 IP 套接字更高效。
不管怎样，你错过了一些选项，例如共享内存。 有些人会将数据库添加到该列表中，但我想说这是一个相当重量级的解决方案。
消息队列也是一种可能，尽管您必须更改内核选项才能处理如此大的消息。 除此之外，它们对很多事情都有一个理想的界面，但恕我直言，它们的使用率很低。
我总体上同意使用现有的解决方案比构建自己的解决方案更好。 我不知道您的问题的具体情况，但我建议您查看 CPAN 的 IPC 部分
UNIX domain sockets are portable across unices. It's no less portable than pipes. It's also more efficient than IP sockets.
Anyway, you missed a few options, shared memory for example. Some would add databases to that list but I'd say that's a rather heavyweight solution.
Message queues would also be a possibility, though you'd have to change a kernel option for it to handle such large messages. Otherwise, they have an ideal interface for a lot of things, and IMHO they are greatly underused.
I generally agree though that using an existing solution is better than building somethings of your own. I don't know the specifics of your problem, but I'd suggest you'd check out the IPC section of CPAN
有很多不同的选项，因为大多数选项更适合某些特定情况，但您还没有真正提供任何可以识别您的情况的信息。
读者/作者是一对一的关系，还是更复杂的关系？
如果读者不在或不再忙碌，你希望作者怎么办？ 反之亦然？
关于您想要的用途，您还有哪些其他信息？
There are so many different options because most of them are better for some particular case, but you haven't really given any information that would identify your case.
Are readers/writers in a one-to-one relationship, or something more more complicated?
What do you want to happen to the writer if the reader is no longer there or busy? And vice versa?
What other information do you have about your desired usage?
对于“交互式”请求（在等待响应（异步或异步）时保持连接打开：HTTP + JSON。 JSON::XS 速度非常快。每个人、所有事物都可以使用 HTTP，并且很容易进行负载平衡、调试……
对于排队请求（“请执行此操作，谢谢！”）： Beanstalkd 和 Beanstalk::Client。使用 JSON 序列化 beanstalk 队列中的请求。
For "interactive" requests (holding the connection open while waiting for a response (asynchronously or not): HTTP + JSON. JSON::XS is insanely fast. Everyone and everything can speak HTTP and it's easy to load balance, debug, ...
For queued requests ("please do this, thanks!"): Beanstalkd and Beanstalk::Client. Serialize the requests in the beanstalk queue with JSON.
Thrift might also be worth looking into depending on your application.