私はアプリケーションを使用しており、この環境で実行するC＃スクリプトを作成できます。この環境には、あらゆる種類のDLLをインポートできます。私の問題は、これらのスクリプト間の通信を有効にしたいということです。環境が制御されていて、アプリケーションのソースコードにアクセスできないため、これを行う方法がわかりません。
私が試したこと：
ファイルI/O：それぞれに読み取ってもらいたいメッセージを.txtファイルに書き込んで、他の人に読み取らせるだけです。問題は、このスクリプトを非常に高速に実行する必要があり、時間がかかりすぎることです。
nServiceBus：これを試しましたが、処理している環境で動作させることができませんでした。私はそれができないと言っているのではなく、ただ私がそれを成し遂げることができないということです。
誰かがこれを行う簡単な方法を知っていますか、それもかなり速いですか？
プロセス間通信の方法は、各メッセージが処理されることがどれほど重要かによって異なります。
たとえば、プロセスAがプロセスBに、たとえばサーバーがダウンしていることを知らせる電子メールをITスタッフに送信するように指示する場合、それは非常に重要です。
ただし、オーディオをストリーミングしている場合、個々のメッセージ（パケット）はアプリのパフォーマンスにとって重要ではなく、ドロップすることができます。
前者の場合は、データベースなどの永続ストレージを使用してメッセージを保存し、各プロセスがデータベースをポーリングして独自のメッセージを取得することを検討する必要があります。このようにして、プロセスが終了したり、他のプロセスとの通信が一時的に失われたりした場合、プロセスが再起動したときに見逃したメッセージを取得できます。
同じプロセス内であっても、プロセス間通信の形式を使用できます。スクリプトを個別のプロセスとして扱い、そのように伝達します。
この状況では、名前付きパイプが適切なオプションになる可能性があります。これらは非常に高速で、.NET3.5でかなり簡単に使用できます。
または、スクリプトが単一のAppDomainに読み込まれる場合は、静的クラスまたはシングルトンを通信サービスとして使用できます。ただし、スクリプトが個別にロードされる場合、これは不可能な場合があります。
答えは簡単です。
任意のDLLをスクリプトにインポートできるため、共有メモリ、名前付きパイプ、TCP / UDPなど、任意の方法でプロセス間の通信を実装するカスタムDLLを作成できます。
さて、あなたの環境の詳細を知らないので、私が本当に提供できることはあまりありません。「C＃スクリプト」という用語を使用しています... C＃は一般にコンパイルされた言語であるため、それが何を意味するのか正確にはわかりません。
通常のC＃を使用している場合、名前付きパイプを使用してWCFを調べましたか？アセンブリが同じ物理マシンで実行されている場合は、名前付きパイプバインディングでホストされるいくつかのWCFサービスを簡単かつ迅速に作成できるはずです。名前付きパイプは、ローカルコンテキストでのシンプルで効率的かつ迅速なメッセージ転送メカニズムを提供します。WCF自体は非常に使いやすく、.NETFrameworkのネイティブコンポーネントです。
ファイルI/Oはすでに配置されているので、RAMディスクに配置することで十分な速度が得られる可能性があります。今日変更をポーリングしている場合、FileSystemWatcherは通信の応答性を高めるのに役立ちます。
PipeStreamを使用できます。メインメモリを使用して行われるため、ディスクIOよりも高速です。
XMPP / Jabberは、jabber.netを参照するもう1つのアプローチです。
もう1つの簡単な方法は、事前定義されたポートでTCPソケットを開き、他のプロセスからそのポートに接続して、その方法で通信することです。