Use memory instead of sockets in IPC ?

[a_agaga]

Do you know are there some reasons why many do not make processes to
communicate through memory?

Why network connections (sockets) are used so commonly in IPC (inter
process communication) instead of memory?

(Is IPC harder to maintain / handle if it is made through memory, when
compared to communication through sockets?)

Some background things:

The processes, which communicate with each others, are on the same PC.
There are some reasons, why the processes have not been combined to one
process.
They have to communicate with each others.

It might be best, if those processes could be combined to one process,
but I have seen many processes, which are on the same PC and those
still communicate with each other through sockets instead of through
memory.

Pipes are used too for some IPC, between some other processes, but
those requests are not so time critical as the requests, which I am
talking about now. So pipes are good to be used in those situations,
those are simple to use.

I think it would be wiser to communicate through memory, where it is
possible and where performance is important. But are there some reason
why processes tend not to communicate through memory, even though
performance would be an important factor?

- - - - - - -

I would have one extra question too:
Many also create the connection each time the request is sent through
the sockets.
Wouldn't it be wiser to keep the connections open all the time instead
of creating them each time when a request is sent?
I assume it is harder to maintain the connections, when connections
break up, if connections are up all the time.
It might be one reason, why connections are created separately for each
request
(and closed after the request has been sent).

If time is not so critical, would it be wise to use sockets instead of
memory then?
Also connections would not need to be kept open then too.



Thank you!

 

[Steve Pope]

Do you know are there some reasons why many do not make processes to
communicate through memory?

Why network connections (sockets) are used so commonly in IPC (inter
process communication) instead of memory?

The basic answer is that IPC by means of reading/writing to
shared memory is too crude. At minimum you would need to
use a locking mechanism (semaphores, or similar) to make sure
your shared-memory operations are atomic and immune to events
such as interrupts. Sockets do all this for you.

A second, related answer is that writing to physical memory is less
safe. If a process accesses only its own virtual memory, it
cannot munge up other processes.

This is the whole idea behind having system calls, of which sockets
are one example -- so that each process does not have to write
into kernel memory and risk screwing up the entire system.
(Not that this isn't still possible through bad system calls, on most
systems.)

Steve

 

[Gianni Mariani]

This is off topic for this NG btw. Perhaps comp.programming might be
better.

I think it would be wiser to communicate through memory, where it is
possible and where performance is important. But are there some reason
why processes tend not to communicate through memory, even though
performance would be an important factor?

There are plenty of examples where shared memory is used. The support
for it is not as easy to find as reading and writing through
pipes/sockets so it tends to be used only where performance matters.

One of the biggest drawbacks is the "corruptability" of the memory. If
one process goes haywire, it can render the other processes reading the
shared memory also broken so the separation is somewhat important for
stability and security reasons.

If you take that into consideration, then it is understandable that
communication through a stream interface seems to be more prevalent.

Also, through magic of virtual memory, many pipe and socket
implementations "twiddle" the VM page tables which allow you to have
what is essentially a stream interface with most of the benefits of a
shared memory interface. Given this, it is even less of an imperative
for performance.

Another reason is that some architectures (PA Risc comes to mind) have
severe limitations on where files are mapped to memory.

Having said all this, there are ways of doing "shared memory" over a
network with support in the kernel to provide synchronization at the VM
level.

- - - - - - -

I would have one extra question too:
Many also create the connection each time the request is sent through
the sockets.
Wouldn't it be wiser to keep the connections open all the time instead
of creating them each time when a request is sent?
I assume it is harder to maintain the connections, when connections
break up, if connections are up all the time.
It might be one reason, why connections are created separately for each
request
(and closed after the request has been sent).

Most applications do keep the connection alive. HTTP does have a
"keepalive" mode which does that as well.

If time is not so critical, would it be wise to use sockets instead of
memory then?
Also connections would not need to be kept open then too.

If time is critical, you should provide a shared memory interface. Many
of the issues I raised earlier can probably be "fixed" by writing some
code to deal with it. For example, the security issue can be solved by
providing private shared memory areas between two co-operating
processes. There is no way I know of doing that without the possibility
of having a third process possibly snoop in on the conversation but
there is no good reason why it could not be easily provided by the
operating systems. Process isolation can easily be done by having 2
shared memory areas, one for each communicating process that only that
process is able o write to, VM's provide this facility today. Finally,
the biggest language issue is you would like to share the objects in
memory if performance is a real issue. The problem here is that
addresses written to shared memory don't translate. It would be nice if
the C++ compiler provided a special "shared vtable" options to objects
with virtual methods, but alas, you would need to do that all by hand
which makes programming using shared objects alot harder.

Windows does have a facility (COM) that does provide "marshalling" of
method calls across process boundaries. While it is very useful, it can
be difficult to use, especially if you have alot of special data types
you need to marshall (Don't even get me started about BSTR). My
knowledge of COM is more peripheral, but I do think that under the
covers it does alot of things in shared memory. From the application
perspective however, it has no knowledge that it is talking to another
process (apart from wierd errors you need to handle).