2012-05-15 12 views
7

Sto lavorando a un'applicazione C# che contiene più servizi Windows che dovranno comunicare tra loro per trasmettere i dati. Questi servizi potrebbero trovarsi sullo stesso computer ma potrebbero essere remoti. Ho cercato di usare WCF per questo scopo ma sembra che WCF sia troppo pesante e abbia un sacco di configurazione extra che, a mio avviso, sembra non necessario (.NET 3.5 è un requisito qui, so che .NET 4 ha semplificato questo)Sostituzione WCF per comunicazione trasversale/macchina

Quindi la mia domanda è, quale sarebbe la migliore alternativa a WCF, oltre al deprecato .NET Remoting che fornisce questa funzionalità?

+0

Lamentarsi la configurazione sembra un po 'meschino. Per quanto riguarda le prestazioni, l'associazione NetTCP è disponibile in 3.5, quindi non è sicuro quale sia la vostra preoccupazione. –

+0

Ero più curioso di sapere se c'erano alternative e cosa potevano essere se ce ne fossero. La ricerca su Google mi rimanda sempre a WCF. Questo viene da qualcuno che di solito programma Java, quindi sono abituato a RMI, EJB, ecc. –

+4

Ho raggiunto più o meno la stessa conclusione. Ho trovato che la configurazione di WCF è complicata e mal documentata, e sotto un thrashing, ho anche trovato dolorosamente lento e un po 'riluttante a rilasciare memoria. Forse l'ho impostato male, ma non era così performante come speravo, e la correzione non era evidente nella miriade di opzioni di configurazione. scrivere il mio framework * leggero * remoto che spero un giorno di ottenere l'approvazione per open-source.Non è stato banale da implementare. A meno che tu non stia cercando di risolvere questo tipo di problemi, rimango con la WCF fino a quando * non * sarà problematico. – spender

risposta

14

Ho utilizzato PInvoke per accedere al runtime di Windows RPC per quasi 8 anni. È malvagio veloce e molto affidabile per quanto riguarda il trasporto. Se combinato con un serializzatore veloce come protobuf-csharp-port, le comunicazioni risultanti sono solide e very fast.

Quindi, per costruire questo da zero-up questo richiede tre parti:

  1. di Google buffer protocollo (protobuf-csharp-port) per la serializzazione.
  2. Il mio CSharpTest.Net.RpcLibrary per il trasporto.
  3. Un po 'di codice colla per riunirli da protobuf-csharp-rpc.

Questi sono tutti disponibili su NuGet nei seguenti pacchetti: Google.ProtocolBuffers, CSharpTest.Net.RpcLibrary e Google.ProtocolBuffers.Rpc.

Di seguito un breve corsa verso il basso su come iniziare:

  1. definire un insieme di messaggi e un servizio utilizzando il Google Protocol Buffer Language.

  2. Una volta definito, verrà eseguito ProtoGen.exe per generare gli stub e i messaggi di servizio in C#. Assicurati di aggiungere "-service_generator_type = IRPCDISPATCH" per generare il codice di servizio corretto.

  3. Ora che i file di origine generati sono stati aggiunti a un progetto e fanno riferimento ai tre assiemi dei pacchetti elencati sopra.

  4. Infine, dare un'occhiata al codice client/server di esempio sulla pagina di progetto protobuf-csharp-rpc. Sostituisci "SearchService" con il tuo nome di servizio e dovresti essere pronto per essere eseguito.

  5. Facoltativamente, modificare la configurazione del client/server RPC. L'esempio mostra l'uso di LRPC che è solo host locale; tuttavia il file sorgente DemoRpcLibrary.cs mostra anche TCP/IP e Named Pipes.

È sempre possibile inviare un'e-mail (roger @ nome utente) per ulteriori informazioni o esempi.

Aggiornamento

ho scritto una guida di avvio rapido: WCF replacement for cross process/machine communication.

+0

Sembra l'alternativa che stavo cercando, grazie per le informazioni! –

+1

@Andrew Landsverk, vedi anche: http://csharptest.net/1177/wcf-replacement-for-cross-processmachine-communication/ –

+0

Wow, grazie per aver trovato il tempo per prepararlo! –

2

Si consiglia di esaminare ZeroMQ, è molto leggero ed efficace e viene fornito con buoni collegamenti C#. (Digitando questo sul mio cellulare quindi dovrai google per te stesso per ora, mi dispiace).

+0

Non chiamerei esattamente ZeroMQ lightweight. –

+0

ZeroMQ è molto buono se non ti interessa una risposta e non sei preoccupato che i messaggi cadano sul pavimento. Come tutte le code, solo il backlog può essere memorizzato. Le prestazioni di ZeroMQ nelle configurazioni di consegna e richiesta/risposta garantite sono particolarmente negative. –

Problemi correlati