Communication between two programs

[onkelhotte]

Hi there,

in my departementI develop a simulation program. Now this simulation will be sold to our customer, but now it has to monitor the machine that I simulate right now. So I have to write an interface to exchange data with another software of a different department. This software will be written in MS C++ 2005.

My question is now: How can I manage such data exchange? I was never confronted with inter process communication. Is it possible to use DCOM or CORBA with IVF? I know that the other departement uses CORBA. From my point of view DCOM would be possible too because they use MS C++ :-) It is also possible, that these two programs run on different computers.

Thanks in advance,
Markus

[jimdempseyatthecove]

Marcus,

What is it that the other department wishes to monitor?
(a progress bar, visualization of partial results, access to raw data of partial results)

If the other department simply wishes to see what you see when you run your simulation on your computer, then I would suggest you not write a program at all. There are programs such as VNC (there are various versions many are free) which permit you to have remote access or a more restrictive remote viewing capability. In your case you would set it up for remote viewing. You would set it up for them to "logg on" to your system with only viewing rights. Then they can see what is on your screen. You can do the monitoring over a LAN or even over the Internet is your connection is fast enough.

For partial results data, a shared file works for me.

Jim Dempsey

[onkelhotte]

My program simulates a process where I calculatedata and show them in diagrams.

The other software now measuresthese data on an industrial machine in real time. Now they want to send me these data, so I can calculate with them and finally show them.

The question is, how can I send and receive data from the other program? I dont want to use textfiles, something like, that I have function or subroutine, which the other program calls and send me the data as arguments.

Markus

[g_f_thomas]

Quoting - onkelhotte

My program simulates a process where I calculatedata and show them in diagrams.

The other software now measuresthese data on an industrial machine in real time. Now they want to send me these data, so I can calculate with them and finally show them.

The question is, how can I send and receive data from the other program? I dont want to use textfiles, something like, that I have function or subroutine, which the other program calls and send me the data as arguments.

Markus

This is usually done via memory mapped files. Ask your VC++ colleagues to look into it.

Gerry

[garylscott1]

Quoting - onkelhotte

Hi there,

in my departementI develop a simulation program. Now this simulation will be sold to our customer, but now it has to monitor the machine that I simulate right now. So I have to write an interface to exchange data with another software of a different department. This software will be written in MS C++ 2005.

My question is now: How can I manage such data exchange? I was never confronted with inter process communication. Is it possible to use DCOM or CORBA with IVF? I know that the other departement uses CORBA. From my point of view DCOM would be possible too because they use MS C++ :-) It is also possible, that these two programs run on different computers.

Thanks in advance,
Markus

An example of using memory mapped files is located here: http://www.fortranlib.com/ShareBufferWin32.f90

That works across programs on a single machine, but not across a network. I use pipes for communication across a network, but don't have a ready example prepared.

[garylscott1]

Quoting - garylscott

An example of using memory mapped files is located here: http://www.fortranlib.com/ShareBufferWin32.f90

That works across programs on a single machine, but not across a network. I use pipes for communication across a network, but don't have a ready example prepared.

Unsure if I can past an image here, but here is an overview (if it appears):

[garylscott1]

Quoting - garylscott

Unsure if I can past an image here, but here is an overview (if it appears):

Oops, sorry. Lets try 'Add files'

[garylscott1]

Quoting - garylscott

Oops, sorry. Lets try 'Add files'

Apologies. I did add the file (I can edit it and see it, but I don't see it when just viewing -- obviously need a forum tutorial). I'll post it online later today. I think a regular RTF editor would work a little better or maybe it just needs to be enabled for images and ole objects.

[garylscott1]

Quoting - garylscott

Apologies. I did add the file (I can edit it and see it, but I don't see it when just viewing -- obviously need a forum tutorial). I'll post it online later today. I think a regular RTF editor would work a little better or maybe it just needs to be enabled for images and ole objects.

DDE seems like a very easy method for network IPC. You can also use the program DDESHARE.EXE to set up the share interactively.

[Jugoslav_Dujic]

Quoting - garylscott

An example of using memory mapped files is located here: http://www.fortranlib.com/ShareBufferWin32.f90

That works across programs on a single machine, but not across a network. I use pipes for communication across a network, but don't have a ready example prepared.

Here's an example with pipes, which I have already posted before... once... The good thing is that they provide automatic synchronization -- the READ in the child process will return only when corresponding WRITE in the parent process is completed (and vice versa). The catch is that you have to communicate the communication channel (pipe handle) somehow. In the example, (which is based on http://msdn.microsoft.com/en-us/library/ms682499(VS.85).aspx), it is done by redirecting child process' standard input and output. In this way, plain Fortran READ and WRITE work on redirected handles. Alternatively, you can use a named pipe.

Now, let me try my luck with file attachment... ZOMG what a complication.

[Jugoslav_Dujic]

Quoting - Jugoslav Dujic

Here's an example with pipes, which I have already posted before... once...

It ended up in limbo, apparently.

[onkelhotte]

Quoting - Jugoslav Dujic

It ended up in limbo, apparently.

Thanks for the MSDN links. Last week Ive found your thread about pipes that you created a few years ago... I thought that pipes wont be appropiate for my problem but I should better take a look into pipes.

Now I have a few buzzwords so that I dont look like amateur in the next meeting ;-)

Markus

[Jugoslav_Dujic]

Quoting - onkelhotte

Thanks for the MSDN links. Last week Ive found your thread about pipes that you created a few years ago... I thought that pipes wont be appropiate for my problem but I should better take a look into pipes.

Now I have a few buzzwords so that I dont look like amateur in the next meeting ;-)

Here's the attachment, hopefully. It takes only 17 steps to upload.

(I thought it should be self-evident how to do it; my IQ is obviously not high enough.)

[g_f_thomas]

Good sample, thanks.

How would two processesshare a chunk of memoryacross a LAN without ever writing the data to a disk file, Windows paging excepted?

Gerry

[jimdempseyatthecove]

Quoting - g.f.thomas

Good sample, thanks.

How would two processesshare a chunk of memoryacross a LAN without ever writing the data to a disk file, Windows paging excepted?

Gerry

Look up memory mapped files. This is not quite the same as shareing a chunk of memory but the system file caching will produce a similar effect. Windows may have a means whereby you can create a NamedMemoryObject that uses the mechanism in memory mapped files to provide a virtual memory portal between processes (even through LAN). Note, Named Pipes are similar too.

Jim Dempsey

[g_f_thomas]

Quoting - jimdempseyatthecove

Look up memory mapped files. This is not quite the same as shareing a chunk of memory but the system file caching will produce a similar effect. Windows may have a means whereby you can create a NamedMemoryObject that uses the mechanism in memory mapped files to provide a virtual memory portal between processes (even through LAN). Note, Named Pipes are similar too.

Jim Dempsey

As someone pointed out earlier, MMF doesn't do LAN. It seems that pipes, sockets, dcom, ... is called for. How do shared COMMON's or struct's work? On the same PC a named COMMON or struct can be shared between processes and unlike mmf and pipes thisdoesn't necessarily involve explicit I/O. Can it be done across a LAN?

Gerry

[g_f_thomas]

Quoting - g.f.thomas

As someone pointed out earlier, MMF doesn't do LAN. It seems that pipes, sockets, dcom, ... is called for. How do shared COMMON's or struct's work? On the same PC a named COMMON or struct can be shared between processes and unlike mmf and pipes thisdoesn't necessarily involve explicit I/O. Can it be done across a LAN?

Gerry

This isn't quite right: you don't need pipes, posix, or dcom after all. Just use .NET Remoting, it works on a PC, over a LAN (we'vebeen using it all along without knowing so), and across domains.

For distributed memory sharing, apparently Windows HPC 2008 Server does it seamlessly and fitsnicely with one of these toys:

http://www.cray.com/products/CX1.aspx

which you can buy on line for $25 - 80K.

Gerry

[onkelhotte]

Quoting - g.f.thomas

This isn't quite right: you don't need pipes, posix, or dcom after all. Just use .NET Remoting, it works on a PC, over a LAN (we'vebeen using it all along without knowing so), and across domains.

Can I use .NET Remoting with IVF, when Fortran is a normal executable?

[g_f_thomas]

Quoting - onkelhotte

Can I use .NET Remoting with IVF, when Fortran is a normal executable?

Since .NET Remoting is limited to managed languages (C#, VB, VC++/C, Leahy and Silverfrost Fortran),obviously no!
However, there is nothing an IVF .exe can do that an IVF DLL can't do, standing alone excepted. Amanagedserver can use the IVF DLL and be accessed by amanagedclientvia .NET Remoting.

Gerry