5

だから私は.NET APIを利用できるアプリケーションを持っています。API ライブラリは、.NET リモート呼び出しを介してメイン アプリケーションと通信します。API を使用するには、アプリケーションがすでに稼働している必要があります。

そのため、プログラムでアプリケーションを起動し、メイン アプリへの IPC リモート チャネルを開こうとする API オブジェクトの 1 つをインスタンス化する必要があるインスタンスがあります。問題は、プロセスを開始した後、起動してからアプリケーションがチャネルを登録するまでに数秒かかることです。チャネルが登録される前に API オブジェクトをインスタンス化しようとすると、ビフアウトします。

.NET リモート処理についてほとんど知らないことは役に立ちません。

アプリケーションが通信用のチャネルを登録しているため、API オブジェクトをインスタンス化しても問題ないことがわかっている場合、API を使用するアプリケーションをどのように判断すればよいですか?

4

5 に答える 5

2

これを試して：

using System.Net.NetworkInformation;
using System.Net;
 private static bool IsPortAvailable(int port)
 {
        IPGlobalProperties globalProperties = IPGlobalProperties.GetIPGlobalProperties();
        IPEndPoint[] activeListeners = globalProperties.GetActiveTcpListeners();
        if (activeListeners.Any(conn => conn.Port == port))
        {
            return true;
        }
        return false;
 }

ポートを渡すと、そのポートにリスナーがあるかどうかを示す値を取得する必要があります。

于 2009-09-25T01:40:07.893 に答える
0

コードの小さなタイプミスです。修正は次のとおりです。

using System.Net.NetworkInformation; 
using System.Net; 
private static bool IsPortAvailable(int port) 
{ 
    IPGlobalProperties globalProperties = IPGlobalProperties.GetIPGlobalProperties(); 
    IPEndPoint[] activeListeners = globalProperties.GetActiveTcpListeners(); 
    if (activeListeners.Any(conn => conn.Port == port)) 
    { 
        return true; 
    } 
    return false; 
}
于 2012-09-19T12:19:56.463 に答える
0

API オブジェクトをインスタンス化する試みを try-catch ブロックにラップすることを検討しましたか? 次に、例外を分析して、サーバーがリッスンしていないことが原因かどうかを確認できます。その場合は、待ってから再試行できます。

理にかなっていますか？

于 2009-10-03T16:05:32.433 に答える
0

箱から出してすぐに、MSMQ で WCF を使用することを考えたことはありますか? あなたがアーキテクチャを完全に理解しているかどうかはわかりませんが、API のクライアントは、API をホストする別のプロセスをスピンアップする必要があるようです。API ホストを開始してから、クライアントが呼び出しを試行するまでの間に、タイミングの問題が発生する場合があります。Microsoft は最近、.NET Remoting (および ASMX Web サービスなどの他のすべての以前の通信テクノロジ) をレガシーとして廃止し、開発者が WCF プラットフォームに移行することを強く推奨しています。

MSMQ で WCF を使用する場合、タイミングの問題は発生しません。API ホストが実行されているかどうかに関係なく、クライアント アプリケーションは永続的なキューにメッセージをドロップできます。API ホストはいつでも開始でき、キューで待機しているすべてのメッセージを取得して処理します。クライアント アプリケーションで API ホストを起動する場合でも、.NET Remoting ではなくキューイングを使用してメッセージを転送しているため、タイミングの問題は問題になりません。WCF は、MSMQ の優れた便利で使いやすいラッパーを提供するため、参入障壁は比較的低くなります。

.NET Remoting で WCF を使用することのもう 1 つの優れた点は、クライアント アプリを変更することなく、API ホストを別の物理サーバーに簡単に移動できることです。必要に応じて、クライアントまたは API ホスト アプリを変更せずに、別のキュー プラットフォーム (AMQP の RabbitMQ など) に移動することもできます。WCF はそのすべての対話を処理し、クライアント アプリと API ホスト間のより明確な分離と信頼性の高い通信を提供します。

WCF に移行できない場合は、.NET Remoting を使用してポートを明示的に設定できるはずです。API ホストをどのように構成しているかはわかりませんが、特定のリモート オブジェクトの URL は通常、次の形式になっています。

tcp://<hostname>[:<port>]/<object>

ポートを追加すると、Abhijeet のソリューションを使用して、ポートが開いているかどうかを判断できるはずです。WCF の疎結合と信頼できる通信の利点は得られませんが、作業は確実に少なくなります。;)

于 2009-10-03T07:18:18.380 に答える