comunicazioni locali tra due app

4

Per creare un programma indipendente dalla piattaforma in C ++, voglio separare la GUI (separata per ogni sistema operativo, usando librerie / API native) e il programma attuale. Ovviamente questi due devono comunicare tra loro.

Fare ciò salvando e leggendo i file XML sarebbe una soluzione. Poiché è un po 'lento / deve sempre essere controllato per le modifiche, preferirei piuttosto una soluzione in cui la parte di elaborazione del programma offre un "server" su localhost e la GUI comunica con quel "server". Cosa ne pensi di questo approccio? E come lo farei tecnicamente?

    
posta ProgrammingMachine5000 15.11.2014 - 15:42
fonte

2 risposte

6

Hai a che fare con un problema di comunicazione tra processi con il vincolo che questo deve essere indipendente dalla piattaforma e con l'altro vincolo (che libera più opzioni di progettazione) che è sulla stessa macchina.

Non c'è nulla di intrinsecamente sbagliato in questo approccio. Ricordo Mathematica utilizza questo approccio (il motore di calcolo ('kernel') e il gui sono due parti separate - questo ti ha permesso di eseguirlo sullo stesso computer, o di mettere il motore di calcolo su un box unix headless e visualizzare la GUI sul desktop). Ci sono molte ragioni per cui questa struttura funziona e funziona bene.

D'altra parte, stai aggiungendo complessità al sistema separando le due parti in modo così rigoroso. Questo può essere un bene, oppure no. Un altro bit con una tale struttura è che la distanza tra le due parti del braccio può consentire alcune opzioni di licenza più semplici (la GUI ha una libreria GPL, ma non si desidera GPL il back-end).

Anche cose simili sono fatte con altri sistemi client / server. Perforce (un sistema di controllo delle versioni) ha un server e client (build personalizzata per ogni piattaforma) - mantenere il client e il server come programmi distinti aiuta a mantenere una separazione delle preoccupazioni piuttosto che avere un'applicazione gigante che può essere più difficile da mantenere. / p>

Collegamento diretto dell'applicazione in quanto un'applicazione può essere l'approccio più semplice con il minor numero di problemi di progettazione ... ma dal momento che non vuoi farlo ...

La risorsa condivisa

Il file condiviso

Il più semplice è quello di un file (o file) condiviso che ciascuno scrive e legge da. È veramente facile (ricordo un gioco dei primi tempi - Spaceward Ho che usava un file condiviso per un gioco di area locale). Funziona, anche se è un po 'goffo.

Il quo condiviso

Una variazione su questo è una named pipe che sembra come un file, ma isn 't. Beh, è un file, nel senso che è un file, ma in realtà è l'output (o input) di un programma a cui è possibile accedere come se fosse un file.

La memoria condivisa

Potresti anche andare con un segmento di memoria su cui più processi possono scrivere. Un bel po 'sulla memoria condivisa è che è più difficile intercettare la sua comunicazione (se questo è un problema). Può anche essere piuttosto veloce. Ciò prende la sincronizzazione appropriata della risorsa. Con i file e i fifo, il sistema operativo spesso ha un po 'di sicurezza per impedirvi di calpestare troppo le dita dei piedi (il file è bloccato, non è necessario scriverlo). La memoria condivisa non ha protezioni così forti da spararti ai piedi.

Segnali

La maggior parte dei sistemi ha una sorta di segnale. Funziona, ma non è in grado di trasportare dati. È più come "hey, svegliati!" digitare informazioni. Quindi, mentre lo elenco qui, non è quello che stai cercando affatto.

Sockets

Probabilmente stai lavorando su un sistema che consente comunicazioni basate su socket. È possibile aprire un socket (ascolto su localhost) e inserire i dati in esso. È davvero semplice. Funziona bene per la comunicazione 1: 1 ... anche se se hai più client, le cose potrebbero diventare un po 'pelose se non te lo aspetti.

Messaggi

Code di messaggi

È possibile attivare (o incorporare) uno di un enorme elenco di code di messaggi. I nomi che sentirai più spesso sono ActiveMQ, ZeroMq e RabbitMQ. Vale la pena esaminare tutti. Se sei aperto ad altre opzioni, ci sono un certo numero di voci commerciali in quest'area. Questi hanno il vantaggio che se si voleva fare qualcosa di altro di C ++ come linguaggio client (per esempio, si scopre che il proprio front end sarebbe meglio servito con .Net su una finestra di Windows), è ancora facile da usare questo.

Passaggio del messaggio (richiamo del metodo remoto / chiamata della procedura remota)

Restare all'interno di una struttura linguistica ti offre alcune altre opzioni. All'interno di Java, ad esempio, c'è Java RMI che consente di chiamare un metodo in una JVM da un'altra JVM.

C ++ non ha RPC o RMI compilati, ma ci sono numerose librerie che forniscono questo. Opzioni come XML-RPC . Farò menzione di parsimonia come qualcosa e anche della sua lingua incrociata.

    
risposta data 16.11.2014 - 07:12
fonte
1

Oltre alla risposta esaustiva già fornita:

Se cerchi un approccio indipendente dalla piattaforma, un framework come Apache Thrift o simile potrebbe valere la pena dare un'occhiata, in quanto sono progettati appositamente per lo scopo della comunicazione indipendente dalla piattaforma e dalla lingua indipendente.

È persino possibile combinare un tale framework con Message Queues o un Service Bus, se davvero ne hai bisogno per la tua particolare applicazione. Quest'ultimo aspetto mi sembra un po 'eccessivo, dato lo scopo delineato nella domanda, ma potrebbe essere utile quando stai già programmando di ridimensionare la cosa a qualcosa di più grande.

    
risposta data 16.11.2014 - 12:00
fonte

Leggi altre domande sui tag