Very Computer

by **John Lindle** » Sat, 07 Nov 1998 04:00:00

What is the recommende method for passing data between two unique
programs. It may be the case that one program has started the other, in
which case is it possible to get the process id of the program and
communicate using this. Ideally I would like ot be able to pass messages
between two programs that have been started independently of each other

Thanks in advance

+----------------------------------------------------------------+
| | _ |_ ._ | o._ _|| _ |
| \_|(_)| || | |_|| |(_||(/_\/ |
| / |
+-------------------------------+--------------------------------+
| WWW | E-Mail |

+-------------------------------+--------------------------------+
| ...Doh said Pooh, suffering from an identity crisis |
+----------------------------------------------------------------+

by **Barry Margoli** » Sat, 07 Nov 1998 04:00:00

Quote:>What is the recommende method for passing data between two unique
>programs. It may be the case that one program has started the other, in
>which case is it possible to get the process id of the program and
>communicate using this. Ideally I would like ot be able to pass messages
>between two programs that have been started independently of each other

Unix has several inter-process communication (IPC) mechanisms. The
simplest is unnamed pipes, which can be used if one process started the
other (the pipe has to be created before forking). If the processes aren't
related, you can use named pipes (aka FIFOs), Unix domain sockets, message
queues, shared memory, or files. The choice of which to use depends on the
design of your programs.

Information about most of these techniques can be found in "Advanced
Programming in the Unix Environment", by W. Richard Stevens.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.

by **W. Richard Steve** » Sat, 07 Nov 1998 04:00:00

Quote:> Information about most of these techniques can be found in "Advanced
> Programming in the Unix Environment", by W. Richard Stevens.

Actually my latest book ("Unix Network Programming, Volume 2: IPC")
is devoted entirely to IPC and discusses many topics not in the two
APUE chapters on IPC: Posix messages, mutexes, condition variables,
read-write locks, Posix semaphores, Posix shared memory, the new
Solaris doors, and Sun RPC. http://www.kohala.com/~rstevens has
all the details.

Rich Stevens

by **Ton** » Sun, 08 Nov 1998 04:00:00

Quote:> > Information about most of these techniques can be found in "Advanced
> > Programming in the Unix Environment", by W. Richard Stevens.

> Actually my latest book ("Unix Network Programming, Volume 2: IPC")
> is devoted entirely to IPC and discusses many topics not in the two
> APUE chapters on IPC: Posix messages, mutexes, condition variables,
> read-write locks, Posix semaphores, Posix shared memory, the new
> Solaris doors, and Sun RPC. http://www.kohala.com/~rstevens has
> all the details.

Why do we need other IPC mechanisms when we could just define
sockets/TCP/IP stack as _the_ way? Isn't UDP/TCP adequate for all by the
most performance intensive apps? And doesn't usage of the stack-based
IPC give us the most flexibility in regards to application partitioning?

Tony
--
Post DIRECT job and contract opportunities to
alt.computer.consultants.ads.norecruiters and eliminate middleman costs!

by **Andrew Giert** » Sun, 08 Nov 1998 04:00:00

Tony> Why do we need other IPC mechanisms when we could just define
Tony> sockets/TCP/IP stack as _the_ way?

It's a mistake to consider that there is such a thing as "the" way.

Tony> Isn't UDP/TCP adequate for all by the most performance
Tony> intensive apps?

No.

Tony> And doesn't usage of the stack-based IPC give us the most
Tony> flexibility in regards to application partitioning?

No.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>

by **Larry Blanchar** » Sun, 08 Nov 1998 04:00:00

> Why do we need other IPC mechanisms when we could just define
> sockets/TCP/IP stack as _the_ way? Isn't UDP/TCP adequate for all by the
> most performance intensive apps? And doesn't usage of the stack-based
> IPC give us the most flexibility in regards to application partitioning?

Well, consider a case within a single machine where several clients put
requests of varying types into a message queue and whichever one of
multiple servers is idle grabs the next message (or the next of a
particular type), analyzes it, and puts it back in the queue with a
message type equal to the pid of a "subserver", which handles the
request and sends the result back to the original client (via the
message queue by using the client pid as the message type).

I'm sure there are multiple ways to handle this example, but I can't
think of one that's simpler than the message queue method I described.
Note that the clients have no idea what process is going to handle their
request, nor do they care.

This is not an "out of thin air" example. I know of a process control
system that uses exactly the scheme described.

--
Larry Blanchard - Old roses, old motorcycles, and old trains
Homo Sapiens is a goal, not a description.

by **Ton** » Mon, 09 Nov 1998 04:00:00

> > Why do we need other IPC mechanisms when we could just define
> > sockets/TCP/IP stack as _the_ way? Isn't UDP/TCP adequate for all by the
> > most performance intensive apps? And doesn't usage of the stack-based
> > IPC give us the most flexibility in regards to application partitioning?

> Well, consider a case within a single machine where several clients put
> requests of varying types into a message queue and whichever one of
> multiple servers is idle grabs the next message (or the next of a
> particular type), analyzes it, and puts it back in the queue with a
> message type equal to the pid of a "subserver", which handles the
> request and sends the result back to the original client (via the
> message queue by using the client pid as the message type).

> I'm sure there are multiple ways to handle this example, but I can't
> think of one that's simpler than the message queue method I described.
> Note that the clients have no idea what process is going to handle their
> request, nor do they care.

So, how is that better than just using the stack via UDP? Create a
server called PostMaster or something and do some multi-casting. With
the UDP approach, it would be easier to move the system components around
the net. PLUS the technique is infinitely more portable than using a
proprietary IPC mechanism.

All I think you've basically said is that it's more efficient when the
interacting processes are on the same machine. Most apps don't handle
United Airline's reservations you know.

Tony
--
Post DIRECT job and contract opportunities to
alt.computer.consultants.ads.norecruiters and eliminate middleman costs!

by **Andrew Giert** » Mon, 09 Nov 1998 04:00:00

[message queue example]

Tony> So, how is that better than just using the stack via UDP?

It's reliable; UDP is not.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>

by **Johan Hellstro** » Tue, 10 Nov 1998 04:00:00

> Tony> So, how is that better than just using the stack via UDP?

> It's reliable; UDP is not.

Please correct me if I am wrong, but that should only apply to networked
applications. If I remember correctly UDP used as IPC mechanism within one
machine is to be considered reliable.

Johan

by **Andrew Giert** » Tue, 10 Nov 1998 04:00:00

>> It's reliable; UDP is not.

Johan> Please correct me if I am wrong, but that should only apply to
Johan> networked applications. If I remember correctly UDP used as
Johan> IPC mechanism within one machine is to be considered reliable.

UDP is not reliable under any circumstances whatsoever.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>

by **Ton** » Wed, 11 Nov 1998 04:00:00

> [message queue example]

> Tony> So, how is that better than just using the stack via UDP?

> It's reliable; UDP is not.

So add a little ack, timeout and retransmission. Then we have something
better because it's more standard than proprietary IPC and more
flexible right?

Tony
--
Post DIRECT job and contract opportunities to
alt.computer.consultants.ads.norecruiters and eliminate middleman costs!

Very Computer

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs

Message passing between programs