I want to send a signal from a C++ application to a C# application. This is only to let the C# program know the other one is running. I already use C# but I'm not really good at C++ yet. Do I have to create pipes or is there a quicker and/or easier way to do this?
IPC is easy using the classic WM_COPYDATA. A good example can be found here.
Related
What's the easiest way to implement lan interprocess communication?
I need process on machine A be blocked until process on machine B send him just a simple string msg
Don't know if it is worth building a whole WCF project.
What Do you say?
Go WCF.
Why creating something on your own, when there is this perfectly suited library? WCF can exactly what you need out of the box. It supports those synchronous blocking calls you need.
Do yourself a favor and learn it, you will not regret.
I had thought there was a win32 "named" object that could be created, potentially able to serve this capability. I'm not spotting it on net searches though. Of course you could try to use the BCL socket mechanisms directly, blocking for a socket accept. You could also try .net remoting, though I'm not sure it would be more light-weight than WCF.
Ultimately WCF might be best. If you use self-hosting, then I don't think it is as heavy-weight as you are thinking.
I'm working with an application, and I am able to make C# scripts to run in this environment. I can import DLLs of any kind into this environment. My problem is that I'd like to enable communication between these scripts. As the environment is controlled and I have no access to the source code of the application, I'm at a loss as to how to do this.
Things I've tried:
File I/O: Just writing the messages that I would like each to read in .txt files and having the other read it. Problem is that I need this scripts to run quite quickly and that took up too much time.
nServiceBus: I tried this, but I just couldn't get it to work in the environment that I'm dealing with. I'm not saying it can't be done, just that I can't get it done.
Does anyone know of a simple way to do this, that is also pretty fast?
Your method of interprocess communication should depend on how important it is that each message get processed.
For instance, if process A tells process B to, say, send an email to your IT staff saying that a server is down, it's pretty important.
If however you're streaming audio, individual messages (packets) aren't critical to the performance of the app, and can be dropped.
If the former, you should consider using persistent storage such as a database to store messages, and let each process poll the database to retrieve its own messages. In this way, if a process is terminated or loses communication with the other processes temporarily, it will be able to retrieve whatever messages it has missed when it starts up again.
The answer is simple;
Since you can import any DLL into the script you may create a custom DLL that will implement communication between the processes in any way you desire: shared memory, named pipe, TCP/UDP.
You could use a form of Interprocess Communication, even within the same process. Treat your scripts as separate processes, and communicate that way.
Named pipes could be a good option in this situation. They are very fast, and fairly easy to use in .NET 3.5.
Alternatively, if the scripts are loaded into a single AppDomain, you could use a static class or singleton as a communication service. However, if the scripts get loaded in isolation, this may not be possible.
Well, not knowing the details of your environment, there is not much I can really offer. You are using the term "C# scripts"...I am not exactly sure what that means, as C# is generally a compiled language.
If you are using normal C#, have you looked into WCF with Named Pipes? If your assemblies are running on the same physical machine, you should be able to easily and quickly create some WCF services hosted with the Named Pipe binding. Named pipes provide a simple, efficient, and quick message transfer mechanism in a local context. WCF itself is pretty easy to use, and is a native component of the .NET framework.
Since you already have the File I/O in place you might get enough speed by placing it on a RAM disk. If you are polling for changes today a FileSystemWatcher could help to get your communication more responsive.
You can use PipeStream. Which are fast than disk IO as they are done using main memory.
XMPP/Jabber is another appraoch take a look at jabber.net.
Another easy way is to open a TCP Socket on a predefined Port, connect to it from the other process and communicate that way.
I have an application in Lua, I want to communicate between the Lua application and a C# program.
I know of several ways to do this in C# (sockets, OS pipes etc) but I can't find any information about these things in Lua (which is a language I'm rather unfamiliar with unfortunately).
The IPC sending and receiving must not block for longer than a few milliseconds, since the Lua script is part of a game and the game will crash if the script takes too long to execute.
Any good links to libraries/tutorials would be greatly appreciated.
The only option I've seen for this would be to use LuaSocket, and communicate via TCP or UDP.
I have a c# winapp that calls a java app by tcp and sends everything back by tcp to the c#.
The reason why I'm using java is because I received a java api. So I wrote a small java app that calls that api and get all the data I need.
So I was wondering if there is another solution for this. Because it's going slow, especially with a lot of data.
Thanks
TCP over the local machine should be pretty fast (named pipes might be a bit faster, but may be harder to do at both ends).
The biggest bottleneck is likely to be serialization and deserialization of the data. What format are you currently using to represent the data?
Sounds to me like you need to profile this. Are you sure it's the network aspect that is slow ? Or the serialisation/deserialisation, or the actual client/server processing beyond the data transmission.
Before you address profiling solutions, you should identify the particular problem point.
You received a java api and you wrote a small java api ... so you know java. Why not write the rest of the application in java as well?
Sometimes is easier to rewrite the "uncompatible" parts dependeing on how much work it is.
I'd recommend trying to use two good Web Service stacks. It would be very interesting to hear your results. It sounds counter-intuitive but these stacks are optimized even though they have the burden of converting to text. Also, it sholdn't be much work to take the stacks in. At least its easy in C# to parallelize calling web services if that's appropriate for your situation.
There are also commercial solutions that allow invoking Java from .NET (and vice-versa). I used JNBridge a few years ago, and it's great.
You can download a 30-day free trial at http://www.jnbridge.com/bin/downloads.php?pr=1&id=0 (no, I don't work for them).
I did some profiling in the java and the method of the api I received are taking the most of the time I noticed.
If I receive around the 1200 records I have a waiting time of 5 minutes. Once I receive it in c#, it only needs a few seconds to add it to objects and show me a view of the results.
So I think the problem isn't really at my end or can it be better if I used something like the JNBridge or webservice?
I have a .net based windows application which is running in memory. I want to trigger one of the function in the app from an external application which is not .net based. How can I achieve this? The triggering should be real time.
Make the first app listen on a TCP port. Make the second application connect to the TCP port and send "WAKE UP LAZY PROGRAM". Make the first app respond to that by doing something.
Using sockets will work.
Named pipes will also work.
If the program weren't .net I'd suggest sending or positing a window message: see PostMessage and RegisterWindowMessage. To receive such a message in the .net program I think you may need to PInvoke RegisterWndowMessage, and override your WndProc.
Another good possibility is to share a named mutex.
You should define what you mean by "real time": on the one hand nothing is real-time on Windows, and on the other hand when you start to back off from that and to say instead "nearly real time" or "soft real time" then many solutions become possible.
Can't you send and XML message string to .net application which is listening in a specific port from the non .net application. By analyzing this XML message you may invoke the specific function in the .net application..
A wild guess.
thanks
123Developer
Message-passing is probably the way to go. Utilizing sockets would work as well, but
a) could open up security vulnerabilities, and
b) could be a problem with firewall software on some machines.
CodeProject has a sample using .NET Remoting / IPC:
Single Instance Application, Passing Command Line Arguments