Remoting vs presa

Question

qual è il diff, vantaggio e svantaggio tra i servizi remoti e la presa ... che è meglio per la funzionalità server-client ....

Answer 1

prese di corrente sono flussi binari prime tra due endpoint. Dovresti avvolgere il tuo livello RPC (etc) per elaborare i messaggi e gestire un sacco di codice di infrastruttura. Tuttavia, dal momento che sono così vicini al metallo, questo può essere molto, molto efficiente. Non è legato ad alcuna architettura specifica, purché entrambe le estremità parlino dello stesso formato di messaggio. Strumenti come protobuf-net possono aiutarti a costruire messaggi binari per i flussi (piuttosto che far ruotare il tuo codice di serializzazione).

Remoting è uno strumento specifico .NET ed è molto poco efficace. Non consiglierei il servizio di remoting per client/server - usa invece cose come WCF.

WCF è uno stack di comunicazioni più flessibile, un sacco di potenza e complessità, ma probabilmente anche un po 'eccessivo (xml, sicurezza complessa ecc.). È basato sul contratto di dati, quindi circa aperto (client/server può essere diverso), ma ancora un po 'focalizzato su .NET.

---

modificare Per info, protobuf-net fornisce uno stack RPC troppo; al momento è disponibile solo un'implementazione HTTP, ma a un certo punto aggiungerò il raw TCP/IP.

Answer 2

La seconda cosa che Marc Gravell ha scritto - in particolare il remoting e la serializzazione interna sono "facili" ma sono molto facili da interrompere e spesso non si adattano bene a una rete pubblica (non mi è familiare con la rete remota, ma Immagino che abbia bisogno di un noto servizio di registro che è spesso problematico quando si esce dall'ambiente di laboratorio pulito).

L'implementazione di un RPC standard o addirittura roll-your-own è più difficile ma più sicuro a lungo termine: non si hanno problemi con le revisioni del codice (o sono più facili da controllare), il ridimensionamento è completamente controllato dal proprio codice, ed è facile sviluppare componenti utilizzando varie tecnologie.

Ci sono molti molti strumenti che ti aiutano a costruire facilmente meccanismi RPC su socket, ma mi piace molto usare il semplice vecchio HTTP - ottenere un semplice server embedded HTTP in esecuzione all'interno del tuo server e il tuo client ha solo bisogno di avere un HTTP client per inviare messaggi. Se si sviluppa la propria semplice semantica di chiamata RESTful (invece di utilizzare qualche formato di messaggio gonfio come SOAP o XML-RPC), allora non c'è quasi nulla da fare :-)

Answer 3

Direi che scegliere tra le prese e la comunicazione remota meglio considerare su quale tipo di applicazione si sta sviluppando. Gli zoccoli sono sicuramente per le tue implementazioni di protocollo, programmazione di basso livello e l'unico modo per andare se devi comunicare alle altre applicazioni TCP/IP. Il servizio remoto è un modo prefezionato per sviluppare nuove applicazioni di comunicazione .NET, in cui non è necessario scendere allo stack tcp/ip e assicurarsi che l'applicazione parli agli altri (probabilmente applicazioni legacy). Nel caso in cui si possa andare solo con .NET è meglio scegliere .NET 3.5 e WCF framework invece di .net 2.0 remoting, l'ultimo è una tecnologia morta e non supportata.

Answer 4

La manipolazione diretta del socket può darvi più potenza, flessibilità, prestazioni e, purtroppo, complessità rispetto a Remoting o WCF. Tuttavia, se sono necessari i vantaggi del protocollo TCP/IP di basso livello, ad esempio i protocolli di I/O non bloccanti e personalizzati, strumenti come Ragel e framework come Mina possono alleviare il carico di complessità. Raccomando di provare le API di livello superiore come prima WCF e usa solo socket diretti se questi non soddisfano le tue esigenze.