About interprocess communications

Let's say I have a program A (written with Delphi 7) running on PC 1 and a program B (written with Delphi 7) running on PC 2. And let's say program A has declared an Array of string named MyStrings.

Is there a way for program B to have access (read and write) to the values contained in MyStrings declared by program A?

Thanks a lot in advance !


Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


check semaphore, it could be util for you to understand the underlying of interprocess concurrecy issue

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
No, you will have to develop some PC-to-PC communications to pass the strings over. You could save a file containing the strings on one PC, then load the strings on the other PC. Or you could use the TServerSocket and TClientSocket to communicate directly, or one of the many other networking components out there (Indy etc). Or you could save the stuff in the Windows EventLog which can be read from the other PC.

Geoff M.
You need to serialize the data structure before transmittal, and parse it on receipt.  Use a sockets conection for most flexibility.

Alternatively, you can use one of the many distributed interfaces that come with Delphi - DCOM, Corba, SOAP, etc.  These have wizards to help you configure them.
Amazon Web Services

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

Wim ten BrinkSelf-employed developerCommented:
There are many ways for B to access data on A, but to do this, A must provide a way to communicate and B must support this communication method.

Since this is PC-to-PC communication, you also need a physical link between these two systems. For example, a null-modem cable or dial-up connection. But these days network communications seem to be everywhere. If you use a null-modem cable or dial-up connection then you have to write quite a lot of code to get things to work. There are libraries that will help you with this but it's still a lot of work. But I assume you use a network so things are a lot easier.

Ways to communicate... Well, you could create a shared folder on A. Then B just monitors this shared folder for any changes and when a change happens, B will determine what has changed and act upon this change. Delphi has the TShellChangeNotifier component (Samples) for this. But this is a file-based communication between two systems and not very efficient if you need a bit more interactive communication.

Another option is the use of named pipes. You will have to use multiple threads then because you don't want one of the systems to freeze until the other system finally sends something to process. Named pipes are also a bit limited to NT/W2K/XP since at least the server needs to use one of these operating systems.

But more popular is just TCP/IP communications and there are several protocols based on this technique, allowing you to use this kind of communication without knowing much about the TCP/IP techniques themselves. They have been mentioned already. CORBA offers a nice platform-independant solution. DCOM and COM+ are more limited to Windows. (COM+ actually for W2K and better.) SOAP is gaining popularity at this moment, mainly because .NET has a good SOAP support. But you don't need .NET to create SOAP solutions. Delphi 7 also has some very good SOAP support.
However, with TCP/IP you tend to fall into client/server solutions, where one of the two systems is considered the server. It's a completely different style of development and requires a different kind of optimization. Don't underestimate the complexity of it.
Alex, where have you been? Both null-modem and TCP/IP comms are extremely easy and can be written in just a couple of pages of code! I haven't tried all this SOAP or CORBA stuff, I don't need the lather right now when our apps talk quite happily with TCP/IP.

AJ, if you are interested, I'll supply code samples. As you have a large choice of ways to do it, I'll wait for you first.

Geoff M.
SOAP is an XML based cross platform mechanism for interprocess communication.  It is typically carried by HTTP.

CORBA (Commom Object Request Brokering Architecture, I think) is the mechanism that Delphi supported in version 3, and Java adopted in J2, for platform independent interfaces over a network.

Both are protocols that sit on top of TCP/IP.  Use of an industry standard protocol buys you oodles of protocol code that you don't need to write and interoperability with other software using that same standard inter-object protocol.
Wim ten BrinkSelf-employed developerCommented:
Geoff, compared to "modern" communications, the null-modem and TCP/IP communication is quite complex. You'll need a good component set to use them or write quite a bit of code yourself to support it.
If I compare this with SOAP, where you define an interface for an object, some server-side code to support the interface and some client-side code to call the object then I can onlu conclude that SOAP is a lot easier for basic communications. I have done quite a bit inter-computer communications and I must admit that SOAP makes things quite easy.
Alex, I'm speaking from real world experience here! Most of the work I do involves simulators for railways. For each simulator, we have a small network of PCs and various hardware devices that use serial comms (bog standard RS232), including touch screens. In both cases the code is very short. The serial comms is specific to each device but in general it is between 2-3 pages of code, nothing more. The network comms is more generic and we have about 100 message types going between the PCs, at quite a rate of knots. The code to handle this is about 11 pages long - this includes connecting, disconnecting, error handling, retries, dissection of messages, and formatting outgoing messages.

As I say, I haven't tried the newer stuff out there as I have no need for it at this moment in time, so I cannot compare them. But I can't imagine that there is much difference?

Geoff M.
The difference is almost no code versus 11 pages.
Ok, so say you had 100 message types that needed to be delivered to 20 units of code (classes). What would be involved in setting that up? How much time spent doing the visual stuff as well, not just code (my stuff is 0 for visual)? Or data structures, mapping tables, etc?

I'm not trying to argue, I just find it extremely hard to believe there is virtually no code. Either that or there is a lot of setting up, so you don't actually see the code.

Geoff M.
>> Either that or there is a lot of setting up, so you don't actually see the code.

Bingo!  By using already programmed protocols, you leverage an enormous code base.  You simply create your classes in accordance with the configurations required by the model, and it works because of the large standard code base that is behind the scenes.

Typically you build a back end business class and a front end proxy class as datamodules with the appropriate interfaces.  The proxy and the back end datamodule "know" each other, so the client side talks to the proxy piece which takes advantage of the code you don't actually see and talks to the server piece via whatever networking infrastructure you have in place.

I am generally not a fan of drag and drop programming, probably for the same reasons you are not, but this is one place where it works very well.

Since SOAP and CORBA are platform independent standards, you can treat Java and C++ objects implementing those standards as native objects in your Delphi code.
Ah, right. I thought it couldn't be as simple as Alex suggested! I did do a bit of research last night so I understand what you mean.

At the end of the day, it's whatever suits the requirements. I'm not sure it'd work for me because of the overhead involved (direct TCP/IP is fast and clean).

Geoff M.
Wim ten BrinkSelf-employed developerCommented:
Well, I still think of SOAP (and CORBA) as a very simple technique compared to the older techniques. Then again, it always depends on the complexity you want in your application. SOAP is a good technique to let one computer make requests to another computer. And yes, you set up a class that runs on the server and this class exports an object interface to whomever want to communicate with it. This interface, once imported in your client, can be used to call the server through simple method calls of the interface. Within the client, the server is just another object.
Configuration of a SOAP application is reasonable easy too since all you need is a webserver. All the client needs is the URL of the server and perhaps some security settings if the server is set up to be secure. This last thing can be quite important for some people and it could be quite difficult if you had to write code yourself to use a good, secure system.
Yes, direct TCP/IP is probably faster but SOAP has it's advantages too...
Then I'd use ICS from overbyte.delphicenter.com.  That's the ifrst piece of advice ever given to me on EE, and the one I pass on most often.
SOAP, being XML based, has serious performance implications.  In small scale systems it is not a big deal.  But in mid range and large systems (1000 to 10000 users) or in performance intensive applications it can be problematical.  Since WINTEL systems are limited in CPU expandability, and Delphi is strictly WINTEL, this can be a real problem.

CORBA has less impact on performance, but it is still a bit of a performance hog.  It gains universality at the expense of performance.  J2EE, being based on Java 2 RMI, is entirely dependent on CORBA, so it has a proven enterprise performance record.  The use of "command" and "facade" object patterns can really reduce the performance impact.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.