Jaki jest najlepszy wybór dla komunikacji między procesami .NET? [Zamknięte]

Czy powinienem używać nazwanych potoków lub .NET Remoting do komunikacji z działającym procesem na moim komputerze?

WCF to najlepszy wybór. Obsługuje wiele różnych mechanizmów transportowych ( w tym Named Pipes ) i może być całkowicie konfiguracja napędzanych. Gorąco polecam przyjrzenie się WCF.

Oto blog, który porównuje wydajność WCF vs Remoting .

Cytat z bloga:

Usługi WCF i .NET Remoting są naprawdę porównywalne pod względem wydajności. Różnice są tak małe (pomiar opóźnienia klienta), że nie ma znaczenia, który z nich jest nieco szybszy. Jednak usługa WCF ma znacznie lepszą przepustowość serwera niż usługa .NET Remoting. Gdybym miał rozpocząć zupełnie nowy projekt, wybrałbym WCF. W każdym razie WCF robi znacznie więcej niż usługi zdalne i dla wszystkich tych funkcji uwielbiam to.

Sekcja MSDN dotycząca WCF

Jeśli jest na jednym komputerze, potoki nazwane zapewniają lepszą wydajność i można je zaimplementować za pomocą infrastruktury komunikacji zdalnej, a także programu WCF. Lub możesz po prostu bezpośrednio użyć System.IO.Pipes .

Jeśli masz na myśli komunikację między procesami, to do tej pory bez problemu korzystałem z .NET Remoting. Jeśli dwa procesy znajdują się na tym samym komputerze, komunikacja jest dość szybka.

Nazwane potoki są zdecydowanie bardziej wydajne, ale wymagają zaprojektowania przynajmniej podstawowego protokołu aplikacji, co może być niewykonalne. Usługi zdalne umożliwiają łatwe wywoływanie metod zdalnych.

Usługi zdalne w .NET Framework 2.0 zapewniają kanał IPC do komunikacji między procesami w ramach tej samej maszyny.

Jeśli używasz .NET Framework 3.0 lub nowszego, użyłbym WCF. Korzystając z WCF, możesz używać różnych powiązań w zależności od kompromisu między wydajnością / międzyoperacjami / itp. że potrzebujesz.

Jeśli wydajność nie jest krytyczna i potrzebujesz współdziałania z innymi technologiami usług sieci Web, będziesz chciał użyć powiązania WS-HTTP. W Twoim przypadku możesz użyć WCF z powiązaniem net-tcp lub powiązaniem potoku nazwanego. Albo powinno działać.

Osobiście uważam, że podejście WCF jest bardziej przejrzyste, ponieważ można wykonywać usługi oparte na kontraktach i skupiać się na komunikatach, a nie obiektach (robię tutaj uogólnienie w oparciu o domyślne modele programowania WCF / .NET Remoting). Nie lubię przesyłać obiektów przez kabel, ponieważ wiele informacji semantycznych zostaje utraconych lub nie jest jasnych. Gdy wszystko, co robisz, to wysyłanie wiadomości, tak jak w przypadku programu WCF, łatwiej jest oddzielić swoje obawy między komunikacją a klasami / infrastrukturą, z których składa się pojedynczy węzeł.

WCF zapewnia również elastyczność. Po prostu zmieniając konfigurację (powiązanie), możesz mieć tę samą usługę na innej maszynie zamiast IPC na tej samej maszynie. Dlatego Twój kod pozostaje elastyczny.

Usługi zdalne w sieci nie są protokołem samym w sobie. Pozwala wybrać protokół do użycia: SOAP, nazwane potoki itp.

Usługa zdalna .net jest wbudowana w .net w celu wykonywania wewnętrznej komunikacji procesu. Jeśli tego użyjesz, będą nadal wspierać i prawdopodobnie ulepszać to w przyszłych wersjach. Nazwane potoki nie dają obietnicy ulepszeń w przyszłych wersjach .net