Communication between applications

Question

I have 3 choices to use : sockets, activeX, com , in order to communicate between applications on one computer. Which is faster ?

Answer 1

As long as this runs on one machine, interprocess communication is fundamentally throttled by the bus bandwidth. A memory-to-memory copy, whether that's done in the TCP/IP stack, the named pipe support code or shared memory. Which makes them all equally efficient.

One detail matters though, the amount of data that's transferred and the number of software layers you travel through to get the job done. The memory bus bandwidth only throttles when the amount of data is large. That isn't necessarily the case for a remote procedure call protocol like COM. Only the arguments of the function call needs to be serialized, that could be only a handful of bytes if you don't pass arrays. Now the overhead starts to matter, there's a fair amount of it when you use a high-level protocol like COM.

The obvious disadvantage of using sockets is that you'll have to write all the de/serialization code yourself. Nontrivial if the protocol with the component isn't simple. Trading your working hours for convenience is the typical choice, only you can make it.

Answer 2

Well, think about it - socket is the lowest level, COM is using sockets, ActiveX is using COM. So which one is faster? Of course, sockets. But that is only if you are asking about program execution speed and data transfer rates. Developing programs using sockets, however, can be much harder if you don't know what you are doing. Not to mention that you possibly can come up with some bad implementation that will be worse than COM. Also, there are not that much of reusable components you can get for sockets as you get using ActiveX, not to mention that if you want to communicate with MS Office, you will have to use COM.

Answer 3

You don't give much detail about what you're trying to do or what considerations you need to make. For example, by "fast" do you mean high bandwidth? Low latency? Is there a possibility you might need to communicate across computers later? Etc.

That said, ActiveX is a special case of COM ( introduction to activeX ). If you're familiar with COM or ActiveX already, and depending on what exactly you're trying to do, you may be able to get away with writing relatively little code because MS dev tools can handle a lot of it for you.

If you're not familiar with it though, it's a fairly complex technology that may be tricky to wrap your head around. So if you're just trying to implement some basic inter-process communication it may be easier to go with sockets. On the other hand, that may require more low level work on your part.

Answer 4

I would also delegate the IPC to a framework eg ACE (adaptive communication framework). Ace's implementation for example, is stable and it's cross platform.

Answer 5

Hi can you use shared memory? Even Oracle use shared memory in their products. Shared memory is fast.

Answer 6

It may not actually matter which is faster. If so then choose the method that will be the most convenient to develop and maintain. It may be possible to save your own time even if you can't save any measurable runtime.

Answer 7

ActiveX is more or less a fancy marketing name on COM (an ActiveX component / control is an object that just supports the IUnknown interface), so your choice is really down to COM vs Socket.

For cross process communication, you can write something faster with sockets... if you're a good socket and Windows programmer, because you will be on your own, as Sockets will basically do nothing to help you. That does not mean COM is not fast, or has bad performance, but you always theoretically can do better than an out-of-the-box system, but only if you master the whole thing.

On last thing, if you need to communicate with 3rd party products or other platforms than Windows, Sockets are more portable.

Answer 8

It's hard to say which is faster, but using COM is certainly the most flexible of the choices you listed. Unless you like grovelling through byte streams.