I am optimizing the parameters of a simulation model that I wrote in C# using an external optimizer.
To allow this external optimizer to 'call' my C# model, I wrote a console application in C# around my model.
The external optimization makes a system call to the console application (the name of this application is an input to the external optimizer).
So far so good.
The problem is that it is not very efficient: every time the console application is called, it needs to initialize my C# model, which takes a lot of time, while in fact I want to run the same model over and over again (thus, initialize it once and then only run it through the console application).
I was thinking about writing another application which initializes my model, keeps running and responds to events raised by the console application (i.e runs the model).
How can I send an event from a console application to a continuously other running application in C#?
Or shouldn't I do this with events at all and use another way of communication.
Named pipes is the simpliest way to organize interprocess communication, it's minimum requirement is using System.IO.Pipes
This question has simple example for named pipes usage
Example of Named Pipes
Related
I have a dotnet core WebAPI web server that needs to execute a native method written in Win32 C++. The problem is, each time this method is called it needs to instantiate a bunch of things before it can do what it needs to do, this adds delays to the request. (It's currently using DLLImport to access the C++ method in the compiled DLL).
What I would like to do is have some sort of long running process start when the server starts, which will handle the initialization once, then have my WebAPI service call a method inside this process that executes the code that I actually need to run immediately, without the need to initialize its dependencies each time. Since this is a web server, the process will need to be able to handle multiple requests at once.
What is the recommended approach for this? I have full access to the C++ code and the WebAPI server code so I'm free to do whatever needs to be done to accomplish this.
You may set-up some IPC infrastructure between the two.
One way to do it would be to make your DLL COM compatible. I.e having the DLL be a COM server to some COM class. The server process would then 'CreateInstance' a class, which will automatically launch your native process. A call would then just be a normal function call, COM will handle the RPC.
Another simpler way will be using a named memory-mapped file. Both processes will open a handle to this, there you can store a queue or some data structure. The server process will push while the native process will pop. You can use windows events to synchronize this. You can write this yourself or use something like boost::interprocess for the C++ part. I assume there may be other IPC libraries you may find for this.
You can also use a Pipe, I know C# has some easy ways to handle windows pipes. Pipes do not need synchronization but to efficiently handle a number of such requests you may need a number of threads on the native process to read from the pipe.
Personally i'd go with using COM if that is possible. As it will hide for you the low-level IPC stuff that may be a pit-fall. It is a bit longer to set-up though.
I'm developing a small multiplayer game, and currently the game server runs in a c# console application.
This limits me because:
the server gets stuck whenever I even start a text select in the console. If I even accidentally touch the console, the server gets stuck and I'm left shocked that the client is stuck somewhy, whereas it gets timed-out as soon as I right click the console and the select is canceled
I'm limited with supplying user input to the server. Say, I want to implement server commands, I have a great system I've written that handles pub-sub messages that I can use, and I just don't have any way to easily send those messages, since the server is console based and I can't rely on console input, when there's a lot of output to the console, and the client (which can publish those messages as well) is XNA base, and there's no easy way to implement a console on the client side (which would be an awesome thing to do, and would somehow solve some of my problems if I found a good library for XNA consoles).
I have several options to choose from -
WPF - I can write the server in WPF instead of a ConsoleApplication. This would give me somehow nice GUI, and it would be relatively easy to integrate since the majority of the code is a library and I wouldn't even need to export events, since I would be able to use my pub-sub system for the events.
Web - I have this picture in my mind - I run an executable which starts a local server, and it would just run in the background, people would be able to connect regularly, but I would be able to access a web page, and control the server through it. It would of course be a different port than the game server itself (I assume), and I would be able to control the server (send commands, kick players, restart rounds, and so on) through it.
What I'm here for, is for your suggestions, first of all. What do you find more suitable, pros and cons.
And if we're talking about a web-based server, what's the most standard way of doing that? I mean... mostly for raising a server, and how the website would communicate with it.
Thanks for reading, and thanks in advance for the advises!
Easiest would probably be to use something like Nancy (which is super simple to use) to process REST commands. You can add a Nancy webhost project to your solution and run it alongside your server, reusing your pub/sub architecture. Bonus, you can then use Nancy for certain client services that may not work as well on the server.
This is in fact similar to what we're doing with out XNA game, except Nancy also talks directly to clients, alongside the server, to serve up certain cpu or database bound data that isn't performance critical. We use redis to handle the pub/sub communication between the Nancy hosts and server instances.
I'm creating an application with background audio player. According to MS requirements, the player is implemented as a separate DLL and lives in another process.
I'm able to pass track name back to my UI process by updating a BackgroundAudioPlayer.Instance.Track object.
However I'd like my UI to also report state of my download buffer.
What IPC method can I use on WP7 to notify my GUI process?
Update: I considered using 4 named manual reset events to pass 4 bits of the data - fail, WP7 only supports unnamed events that are only suitable for thread synchronization within the same process.
I considered System.Windows.Messaging - fail, SendCompletedCallback raises "LocalMessage_CouldNotDeliverMessage", and the documentation says local messaging is not supported on WP7.
So far, I know only one way - write files to isolated storage, and guard them with named mutex. I don't really want to wear out the NAND flash by doing that. Are there better methods? WP7 has WinCE kernel underneath, which has plenty methods available - mailslots, LPC, RPC, COM, pipes, shared memory, and many others - I can't believe none of them is exposed to SilverlightÂ…
How would I make it so that I have one main program with a background process that "listens" for catches (via a function like sendDebugInfo(Exception e) for example) and then unhide the second console and display the message but if the user closes the debug window it doesn't exit the program.
If the above isn't clear enough here is a simple version:
Console application 1 function helloWord() is used
Console application 1 function helloWorld() sends a String to a second console window (but within the same project)
The second console displays "hello world".
You are really asking about inter-process communication (IPC).
There are many ways to achieve IPC. I suggest you have a look at Named Pipes. They are easy to use and quite reliable.
http://msdn.microsoft.com/en-us/library/system.io.pipes.aspx
The basic idea behind Named Pipes is that you have a named resource that you can write messages to in one process and read messages from in the other process. The message can be anything you want. The processes connect to the pipe simply by using the pre-agreed name for it.
Just for clarification, saying that you want two console applications running in different threads is somewhat misleading. Console applications typically run on different processes entirely and since threads are not shared between processes two console applications running in different threads is the norm. However when you say this explicitly it sounds like you're trying to run them on the same process but different threads which I'm not even sure is possible.
That said, Eric J. is right you really seem to be asking about IPC which can be performed in a number of ways. Named pipes is one way and TCP loopback is another. If you want these applications to run on separate machines at some point you're going to want to use TCP. Otherwise named pipes are a lot easier to deal with.
I'd suggest reading up on IPC, figuring out which method suits your needs and try to make it work. When you run into a specific issue like "my messages aren't getting through" or something then you should come back and search for a similar question or create a new question.
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.