I have a .NET \ C# class that loads a structure into memory. There's a C++ application on the same machine that need to be able to query the in memory structure.
My question is around performance. I could expose the functionality as a COM object that the C++ could call via COM ... or I could implement it as a WCF service that I believe the C++ application would be able to query via Named Pipes ...
Does anyone have any experience with performance either way? I've fond some great stats comparing WCF Named Pipes Vs. TCP vs. HTTP, but I don't know enough about COM to make an educated decision on how it'll perform. Any thoughts would be appreciated.
Thanks
Warrick
MS SQL works via named pipes (based on tcp channel, generally speaking), so I think it's perfomance is good enough.
Take a look at Choosing Communication Options in .NET
AFAIK today WCF's named pipes/tcp conversation is recommended way to do interprocessing via network (LAN or global). WCF is the successor of Remoting and supplants COM/DCOM for managed code. But remoting is not deprecated/legacy yet and can be used for cross-appdomain binary communication.
Related
I would like to build a communication protocol between COBOL and C# applications. I didn't find the right way to connect these two applications. The only possible way is to write data by COBOL to a file and read it by C# application and vice versa.
Can I use socket techniques to create such communication, because the file method has bad performance? Or are there any other methods of communicating data between these two languages?
Can I use socket techniques to create such communication [...]?
Of course! You just need to make one a socket server and the other the client + creating + implementing a protocol (if it is just one client + server and you don't need secure communication this is quite easy). You may already have a socket option in your COBOL environment or use external libraries like the free CBL_GC_SOCKET (works for many COBOL implementations, as long as they can call C/C++ binaries).
Or are there any other methods of communicating data between these two
languages?
A multitude (especially if they run on the same machine).
Depending on the COBOL environment used you may have a direct .NET-assembly option and CALL/invoke, or can write a layer to do so with running COBOL code translated to native code within C#.
Direct input/output is often a solution (depends on the needs and the environments, not all have a bi-directional pipe option).
talk to a message queue server (likely not superior in performance)
if the COBOL environment supports it: create a REST endpoint and use this for communication; or do it the other way around talking from COBOL to a REST service implemented in C# (REST from COBOL is likely the "most portable" way of those mentioned, but also the one with the worst performance)
...
Conclusion: there is nothing that hinders COBOL to "communicate" with any reasonable "other programming language", you mainly have to see what you're COBOL and "other programming language" provides and what your goals are.
I have a C# server application and it needs to talk to and control another 3 client applications: one in C#, one in C++ and one in VB.Net. All of them are Windows Form applications. They basically need to exchange some strings and numbers, not heavily loaded. What is the best way to do IPC between C# and those different languages? Note that clients don't talk to each other, they only talk to the server.
C# needs to talk to C++ so I guess WCF isn't good, as WCF only works between two .Net applications?
Can I use named pipes conveniently in all these languages: C#, C++ and VB.Net?
I also want to know if in the future I have to add VB6, VBScript and PowerShell scripts as clients, what would be the best IPC option that works for all these 6 languages? Will I still be able to use named pipes?
Actually WCF configured to expose services via HTTP might be the best option for the list of languages you want to support.
If you don't like WCF consider exposing HTTP REST interfaces i.e. by writing server in ASP.Net MVC.
Named pipes support - C#/VB.Net, C++ - good, VB6 - I don't know, VBScript - definitely not out of the box, PowerShell - yes as it can use .Net libraries.
The fastest solutions for the languages you listed are named pipes and, better still, memory mapped files. Both have implementations in .NET 4.0 and unmanaged C++.
I would recommend looking into memory mapped files. It's relatively straighforward to create a file and an associated view that serve as single-producer, multiple-consumer, unidirectional channel. You can use, say, the first 4 bytes of the area to store the updated value of the last byte written (modulo the view size - 4 bytes) and an EventWaitHandle to synchronise producer/consumer access. Two channels accessing separate memory mapped files will give you a duplex channel.
Links for .NET (C# and VB.NET) and
unmanaged C++.
You may then want to look into Protocol Buffers as a very efficient way to serialise your binary data.
0MQ is an excellent product in the Linux space but the Windows version is somewhat stripped-down, and among other things doesn't support IPC.
There are different libraries you can try such as OpenDDS, ZeroMQ and others. Though ZeroMQ on Windows does not support IPC yet (but supports TCP).
I've got a Win32 C++ game side project and I'd like to create a C# process that can be dynamically attached. The C++ process could then send debug data to the C# process and the C# console could send debug commands to the C++ process. I know this can be done, but I'm not sure how to do it. Anyone know?
There are plenty of ways to communicate cross-process. For your purposes, I would recommend you use Sockets to communicate between the two, as this will also allow you to communicate between machines if you like; and the semantics of using Sockets are similar in both languages.
On the C# Side, you can get started with Sockets by using the Socket or TcpClient class in System.Net.Sockets. Also, you'll probably find it a little bit easier to implement the server / listening side in the C# process.
TcpClient Class # MSDN
Socket Class # MSDN
System.Net.Sockets Namespace # MSDN
On the C++ Side, you have two means of utilizing sockets, either via WinSock functions or Unix/POSIX style functions.
Getting Started with Winsock # MSDN
Winsock Functions # MSDN
Note that the WSA**** functions are the formal WinSock functions, and select/listen/bind/... are the traditional Unix/POSIX style ones. You can use one set or the other.
TCP Sockets are probably your best bet; but you may find that UDP allows you to get started quicker. Also, you could potentially do interesting things with UDP multicast. Don't forget to check your firewall settings if you use sockets.
Other possible means of communicating between the two involve varying amounts of work and domain knowledge that you may need to learn. Here's a brief outline with Pros and Cons.
Named Pipes
Pros: Excellent performance on the same machine, easy to control in C++.
Cons: Difficult to use across machine boundaries.
COM Application Server
Pros: Easy to consume on the C# side. Once created, easy to extend on the C++ side.
Cons: Can be difficult to debug, and it is tricky to add support to an existing project. Also prone to COM registration and debugging headaches. Difficult to learn to use across machine and user-session boundaries.
Shared Memory
Pros: Superb performance, easy to control in C++, moderately easy to control in C#.
Cons: Cannot be used across machines. Has quirks in sharing buffers across processes, though you can always create a buffer for each side, and make communication one-way for the buffers. This is tricky to use if you have more than 1:1 communication between your apps.
We are doing something very similar using named pipes in one of the projects that I am working on. Although I didn't work on the implementation it seems to be doing the job very well. The following link gives a good overview.
http://msdn.microsoft.com/en-us/library/aa365590(v=vs.85).aspx
I have some WCF services running over HTTP and a C++ client using gSOAP to consume them. This works, but we are considering running the service host in the same process as the client, to create a fully local stack.
What is the best way to allow the C++ client to consume these services? Do we still need to use HTTP binding? Or will something like named pipes or NullTransport work? Preferably something that will work with gSOAP or something that we can replace gSOAP with.
if both are in the same process then have them "talk" to each other via direct means. i.e. accessing objects directly. otherwise going over a comms layer is extremely expensive. the same can be said for accessing files on your hard drive via a network share when really going file say c:\foo\something.txt is more productive.
c++ allows you to construct CLR types that are both native code but also CLR-aware. using this technique allows your c++.NET type so to speak from .NET proper. your .NET types will have no idea that they are invoking c++ or vice versa.
have a look in your c++ compiler settings for CLR
A third-party application reads some Java code from an XML file, and runs it when a certain event happens. In Java, I want to tell a .NET 3.5 application, running on the same machine, that this event occurred. The total data transferred each time is probably a few characters.
What is the best way of using Java to tell the .NET process that something happened?
Java doesn't seem to support Named Pipes on Windows, .NET doesn't natively support memory-mapping, and any solution involving web services or RMI is overkill.
If you don't want the full overhead of RMI, you could do direct socket communcation between the two by opening ports and talking to eachother. You'd have to have some way to have both processes agree on which ports to use, how to handshake/etc, but would be simpler than RMI.
ETA: it looks like you can use named pipes from java, you just can't create them? So if the .NET process would create it, you could read/write to it with java. Java just sees it as a file?