in reply to Communicating with a long-running process

If you only want monodirectional IPC, I'd stick with the socket, but use UDP to send it. One advantage of using sockets is that if you ever want to talk to the long running process from a different box, the code need little or no modification.

You could use shared memory. It depends which OS you are on as to which module you would need, but that's more complicated and unless you are doing lots of high speed comms, unnecessary.

You could use Named Pipes, though I've had some problems using these from Perl on Win32 and you rarely see them mentioned for *nix.

On win32 there are a whole raft of other options including Clipboard, COM, Data Copy, DDE, File Mapping, Mailslots, RPC and doubtless some other on *nix too; but from your description, a socket seems the easiest and most appropriate mechanism. And if you ever needed to move to a different platform, it would be the easiest to port.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: Communicating with a long-running process

Replies are listed 'Best First'.
Re^2: Communicating with a long-running process
by tirwhan (Abbot) on Jan 27, 2006 at 17:49 UTC
    I'd stick with the socket, but use UDP to send it

    I'm wondering why? If you issue a command to a process you'll usually want to know that the process received that command at least (as well as possibly whether the command suceeded). You can do these things over UDP but you're then essentially reimplementing TCP features. What am I missing?


    There are ten types of people: those that understand binary and those that don't.
[reply]
[d/l]

      Your right. If confirmation of receipt is required, then stick with tcp. But I'd call that bi-directional comms and my "monodirectional IPC" clause wouldn't apply.

      Of course, you might say that since tcp is available and costs little extra in terms of programming, why not use it to get confirmation anyway. My thinking goes that it depends upon the application, but I could envisage scenarios where the long running process (hereinafter 'the server'), may not get around to checking for incoming commands until it has finished processing the last one--which could be hours or days away.

      It could also be that the command could be sent by any number of clients, but will only be acted upon once. In that scenario, what useful action would either the client or the server take if the command is a duplicate?

      1. Server: "You asked me to do X, but I've already been asked(and done) X";
      2. Client: "Oh. So you've already done, or are about to do X?";
      3. Server: "Yes.";
      4. "Okay then! So long as it gets done.";
      5. "It will."
      6. "Okay, good. So long as it does.".
      7. ""IT WILL! I just told you it would.";
      8. "Okay."
      9. "!"

      :)

      Basically what I'm trying to say there is that UDP continues to have it's place where confirmation is neither required nor useful.

      The main benefit of tcp over udp is the guarentee of delivery or error detection, but within modern LANs, and particularly with the same box, the scope for non-delivery of a UDP message is fairly small. The advantage of UDP is simply that it is quicker because it doesn't require synchronisation between the parties. If either is an advantage to the application, use it. If not, go with tcp.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom