Comunicazione tra applicazioni

Question

Sono disponibili 3 scelte: socket, activeX, com, per comunicare tra le applicazioni su un computer. Quale è più veloce?

Answer 1

Fintanto che questo viene eseguito su una macchina, la comunicazione tra processi è fondamentalmente rallentata dalla larghezza di banda del bus. Una copia da memoria a memoria, sia nello stack TCP/IP, sia nel codice di supporto della pipa con nome o nella memoria condivisa. Il che li rende tutti ugualmente efficienti.

Un dettaglio è importante, la quantità di dati trasferiti e il numero di livelli software che si attraversano per completare il lavoro. La larghezza di banda del bus di memoria è limitata solo quando la quantità di dati è elevata. Questo non è necessariamente il caso per un protocollo di chiamata di procedura remota come COM. Solo gli argomenti della chiamata di funzione devono essere serializzati, che potrebbe essere solo una manciata di byte se non si passano gli array. Ora il sovraccarico inizia a essere importante, c'è una buona dose quando si utilizza un protocollo di alto livello come COM.

L'ovvio svantaggio dell'uso di socket è che dovrete scrivere da soli il codice de/serializzazione. Non banale se il protocollo con il componente non è semplice. Negoziare le ore di lavoro per comodità è la scelta tipica, solo tu puoi farcela.

Answer 2

Ciao, puoi usare la memoria condivisa? Persino Oracle usa la memoria condivisa nei loro prodotti. La memoria condivisa è veloce.

Answer 3

È difficile dire quale sia più veloce, ma l'utilizzo di COM è sicuramente la più flessibile delle opzioni elencate. A meno che non ti piaccia strisciando attraverso i flussi di byte.

Answer 4

Bene, pensateci - il socket è il livello più basso, COM sta usando i socket, ActiveX sta usando COM. Quindi quale è più veloce? Naturalmente, prese. Ma questo è solo se stai chiedendo informazioni sulla velocità di esecuzione del programma e sulle velocità di trasferimento dei dati. Sviluppare programmi usando socket, tuttavia, può essere molto più difficile se non sai cosa stai facendo. Per non parlare del fatto che è possibile arrivare a una cattiva implementazione che sarà peggiore di COM. Inoltre, non ci sono molti componenti riutilizzabili che è possibile ottenere per i socket quando si utilizza ActiveX, per non parlare del fatto che se si desidera comunicare con MS Office, sarà necessario utilizzare COM.

Answer 5

Non si forniscono molti dettagli su cosa si sta tentando di fare o quali considerazioni è necessario effettuare. Ad esempio, per "veloce" intendi un'elevata larghezza di banda? Bassa latenza? C'è una possibilità che potresti dover comunicare tra più computer in un secondo momento? Etc.

Detto questo, ActiveX è un caso speciale di COM (introduction to activeX). Se hai già familiarità con COM o ActiveX e, a seconda di cosa esattamente stai cercando di fare, potresti riuscire a scappare scrivendo relativamente poco codice perché gli strumenti di sviluppo MS possono gestirne molte.

Se non si ha familiarità con esso, è una tecnologia abbastanza complessa che può essere difficile da avvolgere la testa. Quindi, se stai solo cercando di implementare alcune comunicazioni di base tra processi, potrebbe essere più facile andare con i socket. D'altra parte, ciò potrebbe richiedere un lavoro a basso livello da parte tua.

Answer 6

Potrebbe non essere effettivamente importante quale sia più veloce. In tal caso, scegliere il metodo più conveniente da sviluppare e mantenere. Potrebbe essere possibile salvare il proprio tempo anche se non è possibile salvare alcun runtime misurabile.

Answer 7

Vorrei anche delegare l'IPC a un framework, ad es. ACE (quadro di comunicazione adattativa). L'implementazione di Ace, per esempio, è stabile ed è multipiattaforma.

Answer 8

ActiveX è più o meno un nome di marketing di fantasia su COM (un componente/controllo ActiveX è un oggetto che supporta solo l'interfaccia IUnknown), quindi la scelta è davvero verso il basso rispetto a COM vs Socket.

Per la comunicazione cross process, si può scrivere qualcosa di più veloce con prese ... se sei una buona presa e programmatore di Windows, perché sarete da soli, come prese di corrente sarà essenzialmente fare nulla per aiutarvi. Ciò non significa che COM non è veloce, o ha prestazioni cattive, ma tu puoi sempre fare teoricamente meglio di un sistema pronto all'uso, ma solo se hai padronanza dell'intero progetto.

In ultima analisi, se è necessario comunicare con prodotti di terze parti o altre piattaforme rispetto a Windows, i socket sono più portatili.