0

I'm a little stuck here. I have a Server B that is written in C# .NET and communicates with a device I want to work with (e.g. debug it). Then there is Server A (written in C) which communicates with my Eclipse. These two things are no problem at all.

The Problem begins at the point where I need to communicate from Server A to Server B. I can not use the DLLs from B in A since they are written under .NET Framework 2.0 and using those inside C code seems to be rather complicated.

My question is: What are my options here?

There is not a lot of complex data that would have to be transmitted. All of it could easily be transmitted bytewise since the data will be either a string, a number or binary data (executable).

I was thinking about creating a simple protocol which sends byte commands from Server to Server over TCP but I am not sure if this is a good solution.

This is a fundamental design decision since both projects are quite large. I have to decide with care. Any suggestions?

Thanks! (Feel free to edit the tags of this question if you have better ones for me)

Stefan Falk
  • 23,898
  • 50
  • 191
  • 378
  • 1
    Most network communication is inherently language agnostic. Just do some basic research as to how to create a network connection between two processes in each of the two languages. Neither needs to even know what the other side's language is. That's the beauty of networks, you only need to know the network protocol, not any details of the other machine's implementation of it. – Servy Feb 03 '14 at 16:58
  • Well yes I of course but I was hoping that there could be a better way to do this. – Stefan Falk Feb 03 '14 at 17:05
  • So you want to avoid using standard network communication mechanisms to have two severs communicate over a network. That would be *harder*, not *easier* to do. Most languages of course have libraries/frameworks to assist you in network communications. – Servy Feb 03 '14 at 17:07
  • Well these servers are running local. Server does not necessarylily that they communicate over an actual network. In my case here both server would communicate just over localhost. If both servers were separated I wouldn't see any way how to communicate via shared libraries .. – Stefan Falk Feb 03 '14 at 17:09
  • If you want to rely on the fact that they are going to be running on the same machine you can look into different forms of inter process communication, rather than network communication, although network communication is one valid form of IPC. Of course, then you can never move the two servers off of the same physical machine. – Servy Feb 03 '14 at 17:11
  • Sorry but I have to try the obvious. WCF - Windows Communication Foundation – paparazzo Feb 03 '14 at 17:41
  • 1
    @Blam WCF is designed for .NET programs communicating with each other; it's not designed for communicating with a C application. It's *possible* to do it in C, but it'd be no fun at all. You'd be making one half easier in exchange for making the other half *much* harder. – Servy Feb 03 '14 at 18:06

2 Answers2

1

One option would be to use DCOM; here are a couple of articles to get you started: How to write a DCOM server in C#, Calling Managed .NET C# COM Objects from Unmanaged C++ Code. If both the C# and C processes are on the same host, then COM would be sufficient and the code is a bit simpler.

Polyfun
  • 9,479
  • 4
  • 31
  • 39
  • This works under C too, right? Excuse that rather noobish question but I think just enable `Register for COM interop` in Visual Studio is not enogh, is it? – Stefan Falk Feb 03 '14 at 17:31
1

Looking at your comments and seeing how both servers are going to be hosted on the same machine, you could consider using a basic memory mapped file to communicate between the two:

Memory mapped files in C# / Named Shared Memory in C

However, if you want to make this platform independent you could look into using Protobuf which is available for C# and C, amongst others. This would take your idea of creating a TCP protocol, but you use a well documented and industry wide protocol which will make the application easier to support going forward.

Allan Elder
  • 4,052
  • 17
  • 19
  • This looks interesting. What disadvantages would I have to consider on this one? E.g. will a server have to always look if there is something there like consumer/producer? **Server A** would have to wait for a signal of **Server B** and wait/look if **B** is already done. – Stefan Falk Feb 03 '14 at 18:14
  • For protobuf, you can have the consumer follow the traditional Berkley socket pattern; either wait on a read for a specific time and loop through, or wait on an outstanding read indefinitely until data arrives or the connection on the other side is closed. Most implementations I've seen go down the indefinite route, there are occasions where you might have a need to spin in a loop. – Allan Elder Feb 03 '14 at 18:50
  • For memory mapped files, yes, I would think you'd want a signal mechanism in place; its really useful for sharing data, but I don't think theres a mechanism in place where you can be notified when the map is updated. – Allan Elder Feb 03 '14 at 18:53