PureBasic Forums - English

I have a service that I now need to add a UI to. My initial thought was to use tcp/ip (to udp 127.0.0.1:someport) in that this would then allow the UI to connect to remote machines.
But I"m not sure if this is a "needed" feature.

any thoughts on what is going to be the fastest form form of IPC?

Mailslots, shared memory, tcp/ip (tcp or udp), RPC, Pipes?

you could also use WM_COPYDATA for window apps

a VB6 example
http://support.microsoft.com/kb/176058

The fastest form of IPC is shared memory, because the operating system just maps two virtual addresses to the same physical page. Both processes just read and write the same physical memory and there is no need to copy the data between them. The disadvantage of shared memory is that you have to solve many problems on your own. You need some way of notifying the other process if data is available. So you have to query the memory again and again or you use some other notification mechanism like events to pause your process until data becomes available. If you have more than two processes you also have to use some kind of mutex (if they are using the same shared memory) and you cans easily cause some race conditions. I would not recommend to use shared memory as you can easily create some obscure bugs.

A little bit slower are Pipes as the data must be copied between both processes, but you don't have to care about so many things. You can choose between blocking and non blocking pipes (at least in windows), so you can take the variant which suits your purpose. You can increase the speed by writing and reading the pipe with the size of it's internal buffer. If you write many smaller messages, the operating system has to switch between user mode and kernel mode each time. This can consume a noticeable amount of time compared to the time spent on really copying the data. It is also possible to use some tricks to identify the process, which connects, if you are using named pipes (if you are using anonymous pipes, you passed the duplicated handle to the process, so you already know the other process).

TCP/UDP has many things in common with pipes, but it has a slightly higher overhead as the system has to construct at least headers for UDP or even use a full TCP stack. This is only useful if you want to communicate between different hosts.

In your case I would recommend (named) pipes. Anyway, I don't think that you are transferring so much data, that it would make any big difference. Even slow computers can easily handle network traffic of 1 Gbit/s (which would be ~125 MB/s) and some hard drives are not even fast enough to write all this data. If you are not sending a full hd video in raw RGB from your service to the UI, you should not get any problem with all of this methods

DarkPlayer

Nice! thank you.

I had played with shared memory; but the constant checking seemed to slow it down. I'm transferring hundreds of small (sub 1K, more like 200 bytes) packets (up to about 500 packets / second) and I want the ui to keep up. udp is similar, but seemed to be faster in "idle times". I'll futz with named pipes.

Appreciate the info. thanks.
-josh

Have you seen this? WM_COPYDATA

IdeasVacuum wrote:Have you seen this? WM_COPYDATA

Hadn't spotted that -- thanks; will check it out.
One reason I am doing this is the new service requirements of "no ui"
I don't know if I can create a window on all os's for the callback if it's a service... but will give it a try.

This page might help you:
http://msdn.microsoft.com/en-us/library ... s.85).aspx

jassing wrote:

IdeasVacuum wrote:Have you seen this? WM_COPYDATA

Hadn't spotted that -- thanks; will check it out.
One reason I am doing this is the new service requirements of "no ui"
I don't know if I can create a window on all os's for the callback if it's a service... but will give it a try.

Did you come up with a cross-platform solution? I am looking for one...

Thanks.