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.