communication between programs

hi Matt,

What OS are you running on?

Are the programs on the same machine?  (I'm guessing yes)

A few alternatives I can think of are pipes, RPC, and shared memory.  

Simplest is probably sockets.

Fastest is probably shared memory.

Regards,
Mike.

I suggest you use the MapView functions

CreateFileMapping
OpenFileMapping
MapViewOfFile
UnmapViewOfFile

By useing CreateFileMapping with a "(HANDLE)0xFFFFFFFF" file handle, it will create a FileMap using RAM.

You then can use the OpenFileMapping and MapViewOfFile functions in your other thread to access the data you want to share or send.

The MapView functions were specifically design for shareing files and data between process, threads and programs.

Using the MapView functions would be far easier then using sockets, and it's much faster.

Are talking communication between THREADS of the same process or THREADS of DIFFERENT processes?

Threads within the same process share the same memory space and can share heap variables and pointers intimately.  That's what makes them threads...

It's only when you are trying to communicate across process boundaries that things get complicated.

well, if you're talking about sockets then I'm guessing that you'd like an IPC mechanism to facilitate the communiction.

sockets are not the fatest way of doing IPC, but it works everywhere and even on different machines, so if speed is not really an issue than you can use sockets as you have said.

I used a message pump to do this, jhance was chatting about message passing so i went and done this to learn. it would be a cool way to set up a worker thread responding to messages.

#include <conio.h>

#include <stdio.h>
#include <process.h>
#include <windows.h>

DWORD WINAPI message_eater(LPVOID dummy)
{
     MSG msg;

     while(::GetMessage(&msg,NULL,0,0) == TRUE)
     {
          printf("GOT Message %d:%d\n",msg.wParam,msg.lParam);
          Sleep(1000L);
     }
     
     printf("Pump Dead\n");

     return 1;
}

void main(int argc, char *argv[])
{

     DWORD thread_id = -1;

     HANDLE thread = CreateThread(NULL,0,message_eater,NULL,0,&thread_id);

     Sleep(1000L);

     if(!PostThreadMessage(thread_id,0,1,0))
     {
          printf("Exit %d\n",GetLastError());
     }
     if(!PostThreadMessage(thread_id,0,2,0))
     {
          printf("Exit %d\n",GetLastError());
     }
     if(!PostThreadMessage(thread_id,WM_QUIT,3,0))
     {
          printf("Exit %d\n",GetLastError());
     }
     printf("Post out\n");

     getch();

}

The question title is

"Communication between programs."

well sockets then, easy

i only posted that because he was chatting about threads

wow, were to begin, shows I should log on more.

I'll Start from the top:

MDarling: OS is WINDOWS Most Probably some version of 2000 either server or professional.

I'll add some more detail sto my prob at this point.  The master program will be coded by me.  I will then provide it a list of other programs to execute (either from a db or a file).  These wont be programmed by me, but I want to provide a set of common function calls that can be made by them intheir code(maybe using COM) to access information stored in the master program and to pass information back.

Sockets sound like the best alternative as the programs may be held on another server (if its a big program) or a little exe on the same box.

Does this make the decision easier?

Thanks for all the help so far.

I would use sockets, defining a command protocol for use by the other programs.

If you wish to use function calls then you can wrap them in a DLL which which creates messages to send over lower level sockets layer.

However you could achieve the same thing by using RPC if you wish.  My own preference however would be to use sockets.

You could always migrate your server (and/or clients) to linux, HP-UX, whatever in the future if you needed.

Regards,
Mike.

I Think sockets is the way as it is easier to implement,but I need the functionality of RPC, i.e., it would be nice to be able to call certain functions in the parent program that would return only the desired information to the child program,but RPC's are a pain, and they only work with C++ right?  I want to be able to let the programmers use as wide a range of languages as possible, hence why I like sockets (Perl, C, VB, C++, Java, etc)

I've come up with a tidier way of solving my problem,hows this sound.

The I wil store the information my child programs need in an XML file, once all the data has been stored the parent program will launch the child programs.  These will then access the data in the XML file via an API (some COM functions rapped in a DLL).

This way the parent program can write the data to the file as it wants and the child programs can take it at their pace.  The only limitation I can see is that the child programs must be written in languages that suporrt COM,I know C++ and VB do,are there any other?

emmm, i would just use sockets and write an application level protocol, wrap this in a DLL that has an interface for a data giver and data taker, i.e. the parent program being the giver and child programs being takers.

but that means the parent program needs to keep track of how much data has been taken by which child program (as there may be several) as well as communication between the child and parent to know when to stop taking data and if the child program is really big and takes ages then my parent program will be waiting around just to deliver data to it

yes but your application protocol will deal with this.

>>my parent program will be waiting around just to deliver data to it

not if you design it in such a way as a client can ask for data, you could have a few threads, therefore your parent could do what it likes and have a thread waiting for requests from clients. although do not have one thread for each client because this will lead to a fundamentally un-scalable application architecture.

BTW, matt, what on earth is it you are doing ? and hows BT

just doing some research for my final year project.

If I move the client requests from threaded sockets to a DCOM API then my server program can be long gone while the local/remote client programs do there thing getting the data via my API.  Plus it gets me to use XML, which the UNI would probably like :-)

Yeah BT's not bad, only a couple of months left

be careful not to give your self a hard time, dont use XML just because it might ring some lectures bell, you will have a host of file sharing problems to deal with if you use a file, moreover you will have to devise a way to stop clients taking the same work. setting up a communications channel between server and client will be alot more straight forward, wether this channel is pipes, sockets, RPC etc does not matter (the former only being suitable for process on the same host). before using any of these new technologies get a firm grasp on socket programming, then you will find RPC, DCOM etc easier to understand as you will have an understanding of whats really going on beneath the hood of these technologies.

Paul

well I don't mind how many clients access the data as by the time they acces the file via the api it will have been finished being written to.  I figured I would make the API return the info from the XML file in the form of an array, (nice and easy to deal with).

my main concern with having direct contact between the parent and many child programs is the data flow control.  and I think designing/developing and API to read form an xml file and convert to an array would be easier than a whole hoard of interprocess communication stuff (christ that could almost be a final year project on it's own)

when you coming back to BT

september

ok well that solves my communication on the same server using an in-process COM API but it would be nice to build in the ability to scale and allow DCOM, would it still be able to using my existing in process COM calls via the DLL's or would I need to create a whole hoard of EXE's to run over network.  I know this is a lot for 100 pts but I will sort it out later.

i dont know, i should image if you just use DCOM then it will work on one or many machine. if DCOM is location transparent then it wont matter if two processes are on the same or different machines

oh BTW matt i got a first in me degree, sweet :)

sweet

I would develop in COM using DLL's, how hard is it to convert to DCOM?

Matt,

I converted a COM program to DCOM a few years back.

If memory serves, it was mostly a matter of jumping through the various NT security hoops/features to allow DCOM clients to connect to the server process.  DCOMCFG is your friend in this case.

I also seem to recall that I needed to change the server code, which was self-registering, to register properly as a DCOM server.  And some of the error handling changed, due to new failure points introduced by using DCOM.

Oh, yeah, I also added a feature to the server to, upon installation, generate a .reg file for clients to run to use that server.  This made administration a little easier.

I came up with a different way but if you had to stick to C++ then sockets would be the way