4

I am trying to send over image data from a compiled C++ process to a compiled C# process. The C++ process is accessing the webcam and doing some processing on the image. The image is represented by an 2D array of pixels with each pixel value being an 8 bit value (0-255) which is the gray-scale value of that pixel. The image size is 640 by 480.

The C# application does some more processing and displays this image onto the screen. The processes are both running at the same time on my laptop (Windows 7 OS) but I cannot make a single process that does all the steps which is why I need my C++ and C# code to communicate.

I was wondering what is the best way to do this? I read about writing a UDP or TCP server in the C# part and a client on the C++ part, I can then send over the image data as a datagram. I was wondering if this is the best way and if it is whether UDP or TCP would be better?

EDIT: The C++ process is unmanaged C++, I don't have the option to run it as a managed DLL. Could I use named pipes to send over the image?

Finally is UDP guaranteed in order if it is communicating locally? I realise the image would be over the limit for UDP but if it is inorder I should be able to split the images up to send over.

Jkh2
  • 1,010
  • 1
  • 13
  • 25
  • 2
    shared memory might help: http://stackoverflow.com/a/925272/390913 – perreal Mar 06 '12 at 20:27
  • 2
    Typically, you would want to use TCP, since it is reliable and handles packet loss. But in your case, both applications are on the same machine, so there will be no packet loss and you can get away with either. The advantage of UDP is speed. UDP does not check for lost packets and is faster than TCP, so if you were streaming video from your webcam instead of sending a single image at a time, you may see a performance improvement using UDP. – arc Mar 06 '12 at 20:28
  • Possible duplicate of http://stackoverflow.com/questions/539908/interprocess-communication-between-c-sharp-application-and-unmanaged-c-applica – Nick Banks Mar 06 '12 at 20:28
  • 1
    Which parts of the code to you write? Do you use the C++ Part just to access a C++ Library? If you could write all your own Code in C# and you just need to access the Lib you could try `dllimport` – Toby Mar 06 '12 at 21:13
  • @arc: Since TCP packets will also arrive in order and without loss when passing through the loopback interface, UDP is unlikely to give an appreciable difference in performance for OP's case. Moreover, if you ever want to distribute the two processes on separate machines, you'll be guaranteed the code still works if you used TCP. – André Caron Mar 07 '12 at 04:31

6 Answers6

2

If you are writing both of the programs, you can compile C++ one as DLL, and call function that returns an array or some structure from your C# program with DllImport Attribute in System.Runtime.InteropServices namespace.

Onur
  • 599
  • 4
  • 12
2

Interprocess communication can be done via sockets or pipes.

With sockets(TCP and UDP) you're essentially sending the data over the internet to yourself. Luckily since your comp knows itself, the data shouldn't leave the comp so this should be pretty quick. TCP is guaranteed to be in order and has a bunch of other nice features while UDP is pretty much slap some headers onto the data and hope for the best. For this application TCP should be fine. UDP adds unneeded complexity.

Pipes are the other way to have two processes to communicate. You basically have the C++ or C# process create a pipe and start the other process. You just use the pipe like a file: write to and read from it. This can be done in C/C++ using a combination of the pipe, fork, and exec functions or simply using the popen function. C# probably has similar functions.

I suggest using a pipe using _popen, (popen for windows) and writing a series of ints to the pipe and reading it from the other side. This is probably the easiest way... besides using one language of course...

datdo
  • 143
  • 7
1

Why can't you do it in the same process? Is it because you need to mix C# and C++? In that case C++/CLI can be used as a bridge between the environments to have both C# code for the .NET CLR and C++ code compiled natively in one process.

If you really need two processes there are several options when running on a local machine, but a small TCP-based service is probably best. The size of each image will be 307kb which is larger than the 65kb limit of UDP.

Anders Abel
  • 67,989
  • 17
  • 150
  • 217
0

Just move to completely managed code :p (To keep it all in the same process)

https://net7mma.codeplex.com/SourceControl/latest has a C# RtspServer and RtpClient

Jay
  • 3,276
  • 1
  • 28
  • 38
0

I was wondering if this is the best way and if it is whether UDP or TCP would be better?

You usually resort to UDP as a speed optimization when TCP is not fast enough and packet loss is inconvenient rather than when it can't be handled. If you can't handle losing part of the image in the transmission I doubt you can resort to UDP.

Moreover, UDP is unlikely to give a performance boost in your case since you'll be using the loopback interface. This means that all TCP packets are likely to arrive in order and without loss, making TCP extra cheap.

If you write your application using TCP and in the future, for some reason, you decide the processes no longer run on the same machine, you won't have to change your code.

Finally, TCP sockets are just easier to use, so unless TCP is not fast enough on your machine, I would stick with TCP sockets.

is UDP guaranteed in order if it is communicating locally?

AFAIK, this behavior is not guaranteed. It is very likely to work most of the time, but unless you can find a quote from relevant documentation, I wouldn't count on this.

Could I use named pipes to send over the image?

Yes, named pipes are very similar to sockets, but they're known to be slow.

André Caron
  • 44,541
  • 12
  • 67
  • 125
0

Once way of doing it apart from sockets would be to save the image data onto the disk from your C++ application and read it off the disk in your C# application. Of course you will need to make sure some sort of read/write synchronisation so that the file is not read before its fully written.

Or you finally decide to use UDP or TCP, try using RTP. RTP uses UDP with an extra layer of time stamps, sequence numbering to ensure correct order of data delivery. You should be able to find C++ and C# implementations of the protocol. Specifically to mention is that you can send images over a RTP/MJPEG stream if your application is producing JPEG images.