tags:

views:

421

answers:

8

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?

+2  A: 

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.

Reed Copsey
+2  A: 

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.

jrista
+1  A: 

You can use PipeStream. Which are fast than disk IO as they are done using main memory.

affan
+3  A: 

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.

David Lively
Thanks David you brought up a few things I hadn't though about that I should have. Ultimately, it really helped me realize what solution was best for me.
Zach
+2  A: 

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.

Jonas Elfström
+1  A: 

XMPP/Jabber is another appraoch take a look at jabber.net.

kenny
+1  A: 

Another easy way is to open a TCP Socket on a predefined Port, connect to it from the other process and communicate that way.

+2  A: 

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.

Poni
A lot of these answers were very good and most of them I had tried to implement before. It ended up that I could do something that I really didn't think I would be able to, and that was to simply create a class and put all my communication code in there and include that class in both of the other strategies. It's not that your answer was terribly informative but rather it made me realize I was over-complicating the situation. Thank you.
Zach