I’m working on designing a multi-tiered app in Perl and I’m wondering about the pros and cons of the various IPC mechnisms available to me. I’m looking at handling moderately-sized data, typically a few dozen kilobytes but up to a couple of megabytes, and the load is pretty light, at most a couple of hundred requests per minute.
My primary concerns are maintainability and performance (in that order). I don’t think I’ll need to scale up to more than one server, or port off of our main platform (RHEL), but I suppose it’s something to consider.
I can think of the following options:
- Temporary files – Simplistic, probably the worst option in terms of speed and storage requirements
- UNIX domain sockets – Not portable, not scalable
- Internet Sockets – Portable, scalable
- Pipes – Portable, not scalable (?)
Considering that scalability and portability are not my primary concerns, I need to learn more. What’s the best choice, and why? Please comment if you need additional information.
EDIT: I’ll try to give more detail in response to ysth’s questions (warning, wall of text follows):
- 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?
At this point, I’m contemplating a three-tiered approach, but I’m not sure how many processes I’ll have in each tier. I think I need to have more processes towards the left side and fewer toward the right, but maybe I should have the same number across the board:
.---------. .----------. .-------. | Request | -----> | Business | -----> | Data | | Manager | <----- | Logic | <----- | Layer | `---------' `----------' `-------'
These names are still generic and probably won’t make it into the implementation in these forms.
The request manager is responsible for listening for requests from different interfaces, for example web requests and CLI (where response time is important) and e-mail (where response time is less important). It performs logging and manages the responses to the requests (which are rendered in a format appropriate to the type of request).
It sends data about the request to the business logic which performs logging, authorization depending on business rules, etc.
The business logic (if it needs to) then requests data from the data layer, which can either talk to (most often) the internal MySQL database or some other data source outside our team’s control (e.g., our organization’s primary LDAP servers, or our DB2 employee information database, etc.). This is mostly simply a wrapper which formats the data in a uniform way so that it can be handled more easily in the business logic.
The information then flows back to to the request manager for presentation.
If, when data is flowing to the right, the reader is busy, for the interactive requests I’d like to simply wait a suitable period of time, and return a timeout error if I don’t get access in that amount of time (e.g. ‘Try again later’). For the non-interactive requests (e.g. e-mail), the polling system can simply exit and try again on the next invocation (which will probably be once per 1-3 minutes).
When data is flowing in the other direction, there shouldn’t be any waiting situations. If one of the processes has died when trying to travel back to the left, all I can really do is log and exit.
Anyway, that was pretty verbose, and since I’m still in early design I probably still have some confused ideas in there. Some of what I’ve mentioned is probably tangential to the issue of which IPC system to use. I’m open to other suggestions on the design, but I was trying to keep the question limited in scope (For example, maybe I should consider collapsing down to two tiers, which is a much simpler for IPC). What are your thoughts?
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.