Program Communication
Suppose I want two programs on the same computer to have the ability to communicate. What is the best way to go about doing this? Should I just use a networking protocol or is there some API that I'm not aware of that allows you to do this?
sockets / networking is probably your best bet.
you could also use a database if you want. but that is kind of a hack.
these are just 2 ideas off the top of my head. google for "interprocess communication"
you could also use a database if you want. but that is kind of a hack.
these are just 2 ideas off the top of my head. google for "interprocess communication"
But what OS you're talking about ?
And what kind of data you want these programs to transfer ?
And what kind of data you want these programs to transfer ?
Or you can simply look into using WM_COPYDATA (google) which should do what you want very nicely.
You can use a higher-level RPC library, OR you can use one or more of:
Named pipes (win32)
Unix sockets (Unix)
Shared memory (Win32 & Unix)
To send stuff to/from processes.
Be aware that if you share memory between processes, you have to handle locking of it yourself or use a synchronisation protocol over some other channel to negotiate ownership.
Mark
Named pipes (win32)
Unix sockets (Unix)
Shared memory (Win32 & Unix)
To send stuff to/from processes.
Be aware that if you share memory between processes, you have to handle locking of it yourself or use a synchronisation protocol over some other channel to negotiate ownership.
Mark
Avoid using sockets if possible, using them will make firewalls alert users, which might scare them off from using your app.
If you're using windows and have a window handle, then using WM_COPYDATA or even simpler WM_APP to communicate is a good choice.
I'm using WM_APP between two servers atm and it's very easy and quite fast.
As a side note, I need to convert my servers to linux in a couple of months.
How would you do this is Linux (without using sockets)?
Is there a simple interprocess commumication api for linux?
If you're using windows and have a window handle, then using WM_COPYDATA or even simpler WM_APP to communicate is a good choice.
I'm using WM_APP between two servers atm and it's very easy and quite fast.
As a side note, I need to convert my servers to linux in a couple of months.
How would you do this is Linux (without using sockets)?
Is there a simple interprocess commumication api for linux?
Quote:Original post by Anonymous Poster
Avoid using sockets if possible, using them will make firewalls alert users, which might scare them off from using your app.
Hang on, you're saying you want it to use server-server communication without using sockets to avoid scaring users?
Servers are managed by systems managers, who are not scared by applications which use sockets.
Plus I cannot see a method of communicating between servers which DOES NOT use sockets, either directly or indirectly.
Quote:
If you're using windows and have a window handle, then using WM_COPYDATA or even simpler WM_APP to communicate is a good choice.
I'm using WM_APP between two servers atm and it's very easy and quite fast.
How exactly can you use win32 user interface messages for server-server communication? It won't even work between processes on the same machine if they're running inside different window stations or terminal server sessions?
Using USER32 as a interprocess communication library is a severe abuse. It's probably extremely inefficient (after all, it's not designed to do that) and there are other ways in win32 which don't rely on linking user32 (after all, server applications SHOULD NOT link user32)
Quote:
As a side note, I need to convert my servers to linux in a couple of months.
How would you do this is Linux (without using sockets)?
You shouldn't do it without using sockets.
You might be able to do it without using *IP* sockets, i.e. by using Unix domain sockets. These work similarly to NT named pipes - they are a method of processes communicating locally without having to go down to the IP level.
There are also lots of message processing libraries for Unix and NT. Unix has also something called the "system V message passing" system, which has functions such as msgsnd and msgrcv. It's not clear whether this is something which is supposed to be used or is deprecated.
NT named pipes and Unix stream sockets work similarly to a TCP socket - they're a bidirectional stream.
Unix also has Unix datagram sockets which behave somewhat similarly to UDP sockets, except that they are of course, reliable, as there is no physical network.
NT and Unix also both have anonymous pipes which are single-direction streams - these are used for simpler parent-child communications and must be passed when creating the new process.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement