remoting vs gniazda

Question

co jest diff, zaletą i wadą między remoting i gniazdem ... co jest najlepszym sposobem na funkcjonalności klient-serwer ....

Answer 1

Gniazda są surowe strumienie binarne między dwoma punktami końcowymi. Będziesz musiał owinąć swoją własną warstwę RPC (etc), aby przetworzyć wiadomości i zająć się wieloma kodami infrastruktury. Jednakże, ponieważ są one tak blisko metalu, może to być bardzo, bardzo wydajne. Nie jest związany z żadną konkretną architekturą, o ile oba końce mówią o tym samym formacie wiadomości. Narzędzia takie jak protobuf-net mogą pomóc w konstruowaniu wiadomości binarnych dla strumieni (zamiast tasowania własnego kodu serializacji).

Remoting jest narzędziem specyficznym dla platformy .NET i jest bardzo kruchym wersjonowaniem. Nie polecałbym zdalnego przetwarzania dla klienta/serwera - zamiast tego używaj takich rzeczy jak WCF.

WCF jest bardziej elastycznym stosem komunikatów - o dużej mocy i złożoności, ale prawdopodobnie również trochę zbytnim (xml, złożone zabezpieczenia itp.). Jest oparty na danych, więc z grubsza open (klient/serwer może być inny), ale wciąż trochę skupiony .NET.

---

edit Dla informacji, protobuf-net zapewnia stosu RPC zbyt; w tej chwili jest dostępna tylko implementacja HTTP, ale w pewnym momencie dodam surowy TCP/IP.

Answer 2

Po drugie, Marc Gravell napisał - w szczególności remoting i wewnętrzna serializacja są "łatwe", ale są bardzo łatwe do złamania i często nie są dobrze skalowane do publicznej sieci (nie jestem zaznajomiony z .net remoting, ale Chyba potrzebuje dobrze znanej usługi rejestru, która często sprawia problemy podczas wychodzenia z czystego środowiska laboratoryjnego).

Wdrożenie standardowego lub nawet samodzielnego RPC jest trudniejsze, ale bezpieczniejsze na dłuższą metę: nie masz problemów z wersjami kodu (lub łatwiej je kontrolować), skalowanie jest w pełni kontrolowane przez Twój własny kod, i jego łatwe do opracowania komponenty wykorzystujące różne technologie.

Istnieje wiele bardzo wielu narzędzi, które pomagają w prosty sposób budować mechanizmy RPC za pośrednictwem gniazd, ale bardzo lubię używać zwykłego starego protokołu HTTP - pobierz prosty serwer HTTP wbudowany w proces serwera, a klient musi po prostu mieć HTTP klient do wysyłania wiadomości. Jeśli opracujesz własną prostą semantykę wywołania RESTful (zamiast używać jakiegoś nadętego formatu wiadomości, takiego jak SOAP lub XML-RPC), nie ma prawie nic do zrobienia :-)

Answer 3

Powiedziałbym, że wybieranie między gniazdami i zdalne uruchamianie lepiej zastanowić się nad tym, jaki rodzaj aplikacji tworzysz. Gniazda są zdecydowanie dla własnych implementacji protokołu, programowania niskiego poziomu i jedynym sposobem, aby przejść, jeśli musisz komunikować się z innymi aplikacjami tcp/ip. Remoting jest preferowanym sposobem tworzenia nowych aplikacji komunikacyjnych .NET, w których nie trzeba schodzić do stosu TCP/IP i zapewniać rozmowom aplikacji z innymi (prawdopodobnie starszymi aplikacjami). W przypadku, gdybyś mógł skorzystać tylko z .NET, lepiej wybrać platformę .NET 3.5 i WCF zamiast obsługi zdalnej .net 2.0, ostatnią z nich jest martwa i nieobsługiwana technologia.

Answer 4

Bezpośrednia obsługa gniazd może zapewnić większą moc, elastyczność, wydajność i niestety złożoność w porównaniu do Remotingu lub WCF. Jednakże, jeśli potrzebujesz korzyści z niskiego poziomu TCP/IP, takich jak niezablokowane IO i niestandardowe protokoły, narzędzia takie jak Ragel i frameworki takie jak Mina mogą zmniejszyć obciążenie złożoności. Zalecam wypróbowanie interfejsów API wyższego poziomu, takich jak WCF i używanie gniazd bezpośrednich, jeśli nie spełniają one Twoich potrzeb.