2012-02-16 13 views

risposta

6

Rispetto ai tubi, le prese IPC si differenziano per essere bidirezionali, cioè le letture e le scritture possono essere eseguite sullo stesso descrittore. I tubi, a differenza delle prese, sono unidirezionali. Devi mantenere una coppia di descrittori se vuoi fare sia letture che scritture.

I tubi, d'altra parte, garantiscono l'atomicità durante la lettura o la scrittura con una certa quantità di byte. La scrittura di qualcosa di meno di PIPE_BUF byte in una sola volta è garantita per essere consegnata in un blocco e mai osservata parziale. Le prese richiedono più attenzione dal programmatore in questo senso.

La memoria condivisa, se utilizzata per IPC, richiede la sincronizzazione esplicita dal programmatore. Potrebbe essere il meccanismo più efficiente e flessibile, ma a un costo di complessità maggiore.

+0

potrebbe essere il caso di qualche vantaggio di sblocco dei socket IPC? – jasonkim

0

L'utilizzo di una coda di messaggi veri tende a lasciare messaggi di dimensioni fisse. Se si dispone di un numero elevato di messaggi di dimensioni variabili, questo può diventare un problema di prestazioni. L'utilizzo di un socket può essere un modo per aggirare questo problema, anche se a quel punto si finisce di provare a racchiudere questa funzionalità per diventare identica a una coda, il che è difficile da ottenere direttamente nei dettagli, in particolare aspetti come il blocco/non-blocco e l'atomicità.

La memoria condivisa è veloce ma richiede la gestione (si finisce per scrivere una versione di malloc per gestire SHM), inoltre è necessario sincronizzarlo e bloccarlo in qualche modo. Sebbene tu possa usare le librerie per aiutare con questo, la disponibilità dipende dal tuo ambiente e dalla tua lingua.

Le code sono facili ma hanno gli svantaggi elencati come professionisti per la discussione sul socket.

I tubi sono stati coperti da Blagovest risposta a questa domanda.

Come sempre accade con questo genere di cose, suggerirei di leggere i libri di W. Richard Stevens su IPC e prese. Non c'è spiegazione migliore della sua! :-)

1

Forse questa è una risposta troppo semplificata, tuttavia è un dettaglio importante. I socket non sono supportati su tutti i sistemi operativi. Recentemente, sono stato a conoscenza di un progetto che usava socket per IPC dappertutto solo per scoprire che erano costretti a passare da Linux a un SO proprietario che era POSIX, ma non supportava i socket allo stesso modo di Linux.

1

Un altro punto a favore di socket: un'app che utilizza socket può essere facilmente distribuita, ad es. può essere eseguito su un host o distribuito su più host con un piccolo sforzo. Questo dipende ovviamente dalla natura dell'app.

1

Sockets consentono un paio di vantaggi ...

  • È possibile collegare un semplice client per loro per i test (inserire manualmente i dati, vedere la risposta). Questo è molto utile per il debug, la simulazione e il test blackbox.

  • È possibile eseguire i processi su macchine diverse. Questo può essere utile per la scalabilità ed è molto utile nel debugging/testing se si lavora nel software embedded.

  • diventa molto facile per esporre il processo come servizio

Ma ci sono svantaggi pure

  • Overhead è maggiore di IPC ottimizzato per una singola macchina. La memoria condivisa, in particolare, è migliore se hai bisogno di prestazioni e sai che i tuoi processi sono tutti sulla stessa macchina.

  • Sicurezza: se le app client possono connettersi, è possibile chiunque altro, se non si presta attenzione all'autenticazione. I dati possono anche essere annusati se non stai crittografando e modificati se non stai almeno firmando i dati inviati via cavo.

Problemi correlati