Re^2: Communicating with a long-running process

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.

Comment on Re^2: Communicating with a long-running process Download Code

Replies are listed 'Best First'.
Re^3: Communicating with a long-running process by BrowserUk (Patriarch) on Jan 27, 2006 at 18:17 UTC
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? Server: "You asked me to do X, but I've already been asked(and done) X"; Client: "Oh. So you've already done, or are about to do X?"; Server: "Yes."; "Okay then! So long as it gets done."; "It will." "Okay, good. So long as it does.". ""IT WILL! I just told you it would."; "Okay." "!" :) 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]

Replies are listed 'Best First'.

Re^3: Communicating with a long-running process
by BrowserUk (Patriarch) on Jan 27, 2006 at 18:17 UTC

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?

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

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]