Inter-Process Communication in .NET sullo stesso computer

Naviga le tue risposte
2

Voglio dividere un'applicazione C ++ / CLI su due parti:

1. Parte di comunicazione, con I / O + accesso al file di testo:

3 porte COM, 2 prese e 1 file di registro

2. Parte UI, per gestire i dati ricevuti da porte COM, prese ecc ...

Per il momento, la mia applicazione legge costantemente da tutte le porte COM (con alcune scritte quando necessario), comunica con 2 server (invio e ricezione) e registra tutti i dati ricevuti da questi moduli. L'interfaccia utente è anche piuttosto complessa, ma non è rilevante per il mio problema.

Ora, voglio separare le parti di comunicazione del programma, principalmente a causa delle limitazioni delle porte COM (1 connessione allo stesso tempo), per poterle usare su più programmi. La parte di comunicazione deve essere multithread in modo che possa comunicare con tutti i moduli e funzionare sempre (come servizio?).

Ho letto di WCF (perché questa applicazione è stata realizzata con .NET Framework), ma non sono sicuro di questa soluzione: dovrebbe funzionare con una configurazione bassa (Intel Atom a 1.66GHz, 2 GB di RAM, Windows XP Embedded, .NET Framework 4.0).

Posso provare a imparare WCF per risolvere qualcosa, o dovrei trovare un'altra soluzione a causa della configurazione bassa? Idealmente, voglio creare un programma che sia in grado di attivare alcuni eventi nella parte dell'interfaccia utente.

    
posta AlfredLamoule 17.10.2016 - 13:46
fonte

2 risposte

1

Attualmente sto lavorando a un software complesso che sembra simile al tuo che usa WCF piuttosto con successo. Quando l'applicazione WCF viene eseguita all'esterno di un ambiente di server Web, si chiama self-hosting e suggerisco di evitare tutti gli strumenti di generazione dei riferimenti di servizio forniti da Visual Studio e configura manualmente server e client . È molto più semplice da mantenere e una volta ottenuta una configurazione che funziona per te è piuttosto semplice.

Tuttavia, se si hanno problemi di prestazioni (che avrebbero senso dato l'hardware) e vedendo che metà dell'applicazione è C ++, raccomanderei named pipe . I pipe nominati sono in circolazione da un po 'di tempo e in Windows sono trattati dal sistema operativo in modo simile a un flusso di file in memoria che entrambi i processi possono leggere e scrivere, quindi sono piuttosto veloci.

Per ottenere il meglio da entrambi i mondi (o un compromesso di entrambi, a seconda del punto di vista;)) WCF fornisce un named pipe binding , sebbene non l'abbia mai usato.

Ricorda inoltre che questa domanda è stata posta prima:

link

link

    
risposta data 17.10.2016 - 14:36
fonte
0

Se sarà il solo computer che non dovresti usare WCF, WCF è potente ma complesso. Preferisco pensare di isolare il codice di comunicazione hardware in un assembly DLL che potrebbe avere classi separate per diversi hardware di comunicazione, tutti implementando la stessa interfaccia.

Quindi basta che la GUI crei oggetti in base a un file di configurazione (come 3 diverse porte COM con le relative impostazioni) e parli all'interfaccia di ciascuna istanza.

La capacità di distribuire i moduli di acquisizione dei dati potrebbe essere allettante, nel qual caso, dopotutto, WCF potrebbe esserlo. È scalabile in modo gradevole, può utilizzare TCP a basso livello su una LAN e http su una WAN ugualmente, tutto gestito per te.

Lo fa anche con i pipe se lo si desidera (per la comunicazione sulla stessa macchina) ma nella mia esperienza il guadagno di prestazioni su TCP è trascurabile.

    
risposta data 17.10.2016 - 14:53
fonte

Leggi altre domande sui tag

Come integrare la validazione di Jquery nel modulo web ASP .Net Il problema della miniera d'oro può essere risolto utilizzando divide et impera?