Come posso sapere se un'altra app ha registrato un canale Remoto IPC?

Question

Quindi ho un'applicazione con API .NET disponibile. La loro libreria API comunica con la loro applicazione principale tramite le chiamate remote .NET. Per utilizzare l'API, l'applicazione deve essere già attiva e funzionante.

Quindi, ho un'istanza in cui è necessario avviare l'applicazione a livello di codice e quindi creare un'istanza di uno degli oggetti API, che tenta di aprire un canale remoto IPC nell'app principale. Il problema è che, dopo aver avviato il processo, ci sono alcuni secondi tra l'avvio e quando l'applicazione registra il canale. Se provo a creare un'istanza di un oggetto API prima che il canale sia registrato, si biffica.

Non aiuta che io sappia molto poco su .NET remoting.

Come determinare dall'applicazione MY che utilizza la loro API se l'applicazione THEIR ha registrato il canale per la comunicazione quindi so che è opportuno creare un'istanza del proprio oggetto API?

Answer 1

Prova questo:

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; 
} 

Passo nel porto e si dovrebbe ottenere un valore che indica se c'è un ascoltatore su quel port.Hope questo aiuta

Answer 2

solo per uscire dalla scatola per un momento, hai pensato di usare WCF con MSMQ? Non sono sicuro di comprendere appieno la tua architettura, ma sembra che il client dell'API debba avviare un altro processo che ospita l'API. Potrebbe esserci un problema di temporizzazione tra quando si avvia l'host dell'API e quando il client tenta di effettuare chiamate. Recentemente Microsoft ha deprecato .NET Remoting (e tutte le altre tecnologie di comunicazione precedenti come i servizi Web ASMX) come legacy e raccomanda vivamente agli sviluppatori di passare alla piattaforma WCF.

Se si utilizza WCF con MSMQ, non si dovrebbe avere un problema con i tempi. L'applicazione client può rilasciare i messaggi in una coda duratura indipendentemente dal fatto che l'host API sia in esecuzione o meno. L'host API può essere avviato in qualsiasi momento e raccoglierà ed elaborerà tutti i messaggi in attesa in coda. Anche se l'applicazione client avvia l'host API, il problema di temporizzazione non sarebbe più un problema, in quanto si utilizza la messa in coda per trasferire i messaggi anziché .NET Remoting. WCF fornisce un involucro bello, conveniente e facile da usare intorno a MSMQ, quindi la barriera all'ingresso è relativamente bassa.

L'altra cosa bella dell'utilizzo di WCF su .NET Remoting è che è possibile spostare facilmente l'host API su un server fisico diverso senza dover modificare le app client. Potresti persino passare a una diversa piattaforma di accodamento se lo desideri (come RabbitMQ su AMQP), senza modificare le app host client o API. WCF gestisce tutta questa interazione per te, fornendo un disaccoppiamento molto più pulito e comunicazioni più affidabili tra l'app client e l'host API.

Se lo spostamento verso WCF non è un'opzione, dovresti essere in grado di impostare esplicitamente la porta con .NET Remoting. Io non sono sicuro di come si sta configurando il vostro ospite API, ma l'URL di un dato oggetto telecomandato è di solito sotto forma di:

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

Se si aggiunge la porta, allora si dovrebbe essere in grado di utilizzare la soluzione di Abhijeet a determinare se la porta è aperta o meno. Non otterrete l'accoppiamento libero e i vantaggi di comunicazione affidabili di WCF, ma sarebbe sicuramente meno lavoro. ;)

Answer 3

Hai considerato di completare il tentativo di istanziare l'oggetto API in un blocco try-catch? Quindi puoi analizzare l'eccezione e vedere se è stata causata dal mancato ascolto del server. E se lo fosse, puoi solo aspettare e riprovare.

Ha senso?

Answer 4

Solo un piccolo refuso nel codice. correzione è la seguente:

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; 
} 

Answer 5

Quando si registra un IpcServerChannel fa una named pipe per comunicare sopra con il nome del nome della porta si è scelto per la vostra IpcServerChannel. Puoi guardare l'elenco dei Named Pipe per vedere se il tuo Nome Port è lì.

System.IO.Directory.GetFiles(@"\\.\pipe\").Any((path) => path.Contains(@"\\.\pipe\" + pipeName));