5

We are building a new vision inspection system application. The actual inspection system needs to be c++ for a number of reasons. For that system we will be using Boost & Qt.

For our UI, we are currently looking at using WPF/C# for the UI and SQL based reports. The complicating factor that UI has to run both local on the same box as the c++ inspection system or remotely on another box if the inspection system has no monitor or keyboard.

Our concern is what is the fastest way to transfer data between the two systems? We are currently looking at a socket based system using Google protocol buffers for serialization. The protocol buffers will generate code for c++ and c#(jskeet/dotnet-protobufs).

Does anyone have any suggestions/experience?

Richard Cook
  • 32,523
  • 5
  • 46
  • 71
photo_tom
  • 7,292
  • 14
  • 68
  • 116
  • TCP and protobuf sounds good. Do you have specific concern or question? – dtb Oct 08 '10 at 02:23
  • 1
    [protobuf-net](http://code.google.com/p/protobuf-net/) seems to be the preferred protobuf implementation for .NET. – dtb Oct 08 '10 at 02:24
  • This is an area where I don't have a much of experience. I was wondering if there were better options. – photo_tom Oct 08 '10 at 02:43
  • 1
    It depends largely on the interaction styles you need. Your question doesn't tell a lot on what/how you want to communicate between your two systems. Your application might benefit from a message queue infrastructure as foundation; architectural decisions could be made much easier if you follow a RESTful approach. It really depends on what you want to do. If all you need is raw performance, you can invent your own protocol based on sockets and protobuf and it will work. – dtb Oct 08 '10 at 02:58
  • How often/many/large communication units, with what reliability/throughput/latency guarantees, what authorization/authentication/confidentiality requirements, a message/service/resource oriented architecture, etc. – dtb Oct 08 '10 at 03:07
  • @dtb Good questions. However, things are much simpler in this case. Security is not an issue because systems are on an isolated net inside the firewall. Guaranteed response issues are handled in design. We just assume that they are all skewed toward bad and design accordingly so that as long as network is still working, system will work around those issues. We are still working on overall communications architecture, so that is all TBD. Your comments have been extremely helpful, thanks. – photo_tom Oct 08 '10 at 18:35

2 Answers2

1

If you're really looking for the fastest way to communicate with your c++ inspection system, then I would implement both cases. A local interface by using named pipes (see here Interprocess communication for Windows in C# (.NET 2.0)) and a remote interface using Google protocol buffers for situations where your inspection system don't have a keyboard and/or monitor attached. Then the UI first tries opening a named pipe on the local box and if that fails the user has to enter a remote address for socket communication.

Hope that helps a bit...

Community
  • 1
  • 1
VitaminCpp
  • 314
  • 1
  • 4
  • 11
  • 1
    Great Link, thanks. Followed links on SO Question 50153 to named pipes binding class(http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx). Really interesting, however, from a comment on MSDN page, it appears that there is a hidden limit of 16k to 20k per message. This may cause us a problem as we do have some messages blocks that are going to be larger than this. – photo_tom Oct 08 '10 at 13:51
0

I would look at zeromq if you really want the fastest at least cost

Neal Davis
  • 648
  • 6
  • 21