Inter Program communications

Started by
9 comments, last by MaulingMonkey 18 years, 10 months ago
How does php and MySQL communicate? I am assuming that they use sockets? Is there any other way to get different programs to communicate on the same local computer? For example when I ask the window manager for a window, how is the requesting done on linux between X and the program? (I know windows OS handles them) I also remember lightwave having a 'hub' program in the taskbar which the others (modeler and scene/animator) all coordinated their tasks with.
Advertisement
In addition to sockets there are pipes, file-based streams, and message queues. I believe some Windows programs communicate by dumping messages on their respective queues.
Quote:Original post by tychon
In addition to sockets there are pipes, file-based streams, and message queues. I believe some Windows programs communicate by dumping messages on their respective queues.


but aren't pipes command line only? and plus they can't make to programs already running send a message to one another.
Quote:Original post by Genjix
but aren't pipes command line only? and plus they can't make to programs already running send a message to one another.


Nope, pipes and named pipes are a common way to do IPC.

some MSDN information
HardDrop - hard link shell extension."Tread softly because you tread on my dreams" - Yeats
Quote:Original post by Genjix
but aren't pipes command line only? and plus they can't make to programs already running send a message to one another.


The | on a command line is merely a command that takes the stdout stream from the l-val and puts it to the stdin of the r-val.

Snipped directly from the MSDN's definition of a pipe, "A pipe is a section of shared memory that processes use for communication. The process that creates a pipe is the pipe server. A process that connects to a pipe is a pipe client. One process writes information to the pipe, then the other process reads the information from the pipe."

Here is the MSDN section on Windows IPC, if you want a better idea of how to use pipes in Windows and such. They're not quite as comfortable as *NIX, but they work.

If you need a *NIX reference, just let me know and I'll shoot you a page or two.
Quote:Original post by DigitalDelusion
Nope, pipes and named pipes are a common way to do IPC.

some MSDN information


Guess I should refresh a little more often. Hah.
Quote:Original post by Genjix
How does php and MySQL communicate? I am assuming that they use sockets?

Yes.
Quote:Is there any other way to get different programs to communicate on the same local computer?

Yes. Pipes (named and un-named, as allready mentioned) can be fairly useful in this regard. Other methods include shared memory (which can be the fastest mechanism for high bandwidth communications) and simply tossing around files (e.g. program A produces file B which is then read by program C).
Quote:For example when I ask the window manager for a window, how is the requesting done on linux between X and the program? (I know windows OS handles them)

By default, sockets - X is meant to be able to work over a network (I've even used it as such). There's a couple of extensions to the X protocol meant for 3d hardware acceleration (DRI, and I froget the name of the other - I don't THINK I made it up...) which, if my poor memory serves, use shared memory to speed up I/O.

The nice thing about sockets is that they're flexible. Not only can use use them for local communications, but you can also use them to communicate halfway across the planet.

The nice thing about pipes is that they're easy to use. Well, easier, anyways.

The nice thing about shared memory is it's the fastest, and in some instances can be the easiest to use. It's downfalls are that the support code tends to be platform specific, and it can be much harder to convert to a network socket later on (depending on how well encapsulated your access to shared memory is).

EDIT: What is wrong with me, these past few days my english has been about as bad as Derek's...

[Edited by - MaulingMonkey on June 10, 2005 8:33:56 AM]
cool thanks all. i didn't know pipes were so flexible, i wondered what was the best way to write to stdin :P
I can find out sockets on *nix platforms fairly clearly, so don't bother giving me a tutorial.

Just some questions
- Can multiple programs share the receiving and sending ends?
- How can I learn about shared memory (does this involve low level assembly?)
- Can I initialize a pipe or shared memory halfway through execution of my program?
- with shared memory is there a limit to whats shared (can I share a window reference for instance?)
Quote:Original post by Genjix
cool thanks all. i didn't know pipes were so flexible, i wondered what was the best way to write to stdin :P
I can find out sockets on *nix platforms fairly clearly, so don't bother giving me a tutorial.

Just some questions
- Can multiple programs share the receiving and sending ends?

Possibly with named sockets, it's been awhile since I've used them.
Quote:- How can I learn about shared memory (does this involve low level assembly?)

No assembly, just API calls :-). The MSDN should have info on the windows API calls... letsee... This should give you a start on that. For BSD-style memory mapping (should be available on most linux boxes) check your mmap manpage and/or google. this page seems to cover IPC in general, both System V IPC (including segments), and then the previously mentioned BSD mmap.
Quote:- Can I initialize a pipe or shared memory halfway through execution of my program?

Yes.
Quote:- with shared memory is there a limit to whats shared (can I share a window reference for instance?)


Yes. In general, handles don't transfer so well - file handles, device contexts, etc, don't transfer so well because some of the tracking data is stored in a specific area of the program. It's easier just to share things like filenames, or share an area of memory and then copy to/from that area on behalf of the other program.

For example, if I had program A which had a window, and I wanted program B to be able to draw to it, I might create a shared memory area. Program B would write to this area, and program A would then copy this data into the actual window.

Pointers also don't transfer so well - the same memory area may have a different address in both programs. This can be dealt with by storing offsets instead.

As an example, let's take two programs, A and B. Both have mapped an area of memory and stored the start in a pointer called "memory_map":

char * memory_map;

To transfer a basic integer from program A to B, in program A we can do:

int * place_to_store_integer = (int *)memory_map;
*place_to_store_integer = basic_integer;

And in program B we can do:

int * place_integer_is_stored = (int *)memory_map;
int basic_integer = *place_integer_is_stored;

Viola, we now have the same integer. But if you printed out the addresses of place_to_store_integer and place_integer_is_stored, you'd find out they're most likely different addresses. This is because each program has it's own memory space.

To redo the example, instead of using the very start of our memory map, let's use 4 bytes into it. In program A we can do:

int * place_to_store_integer = (int *)(memory_map + 4);
*place_to_store_integer = basic_integer;

And in program B we can do:

int * place_integer_is_stored = (int *)(memory_map + 4);
int basic_integer = *place_integer_is_stored;

Easy as pie. Now, let's not calculate place_to_store_integer from a memory_map offset - assume somewhere else in the program we set it to someplace within the memory map. In order to make sure program B uses the same offset we do, we first have to calculate the offset in program A. This isn't hard:

int * place_to_store_integer = ????;
unsigned int offset = (place_to_store_integer - memory_map);

Voila. Now, if program B recieves offset somehow (by checking an integer at another offset) it can use that to create it's own pointer:

int * place_integer_is_stored = (int *)(memory_map + offset);
int basic_integer = *place_integer_is_stored;


It might not be the best of mini tutorials, but I hope it helps explain the basics :-).

[Edited by - MaulingMonkey on June 10, 2005 10:54:53 AM]
most excellent. thank you very much.

This topic is closed to new replies.

Advertisement