[Sample] Komunikacja TCP/IP

Odnośnie opisu, to według mnie atrakcyjniejsze byłoby podejście top-down, w którym najpierw przedstawiana byłaby koncepcja całego rozwiązania (ot na przykład wyjaśnienie, co to jest pakiet, z czego jest zbudowany, czy można go rozszerzać), a dopiero dalej, jeśli w ogóle, poruszane byłyby zagadnienia związane z implementacją. Myślę, że to właśnie koncepcja jest istotna i może zachęcić do zerknięcia w kod, a nie odpowiedzialności poszczególnych klas. Proponowałbym również przenieść link do archiwum z kodem źródłowym na sam koniec notki, wydaje mi się, że byłby wtedy bardziej zauważalny.

Mam pewną uwagę do organizacji kodu: byłoby dużo wygodniej, gdybyś wrzucił kod klientów i serwera do jednej solucji. Do jego uruchomienia wystarczyłaby wtedy tylko jedna instancja Visual Studio z poprawnie skonfigurowaną opcją Multiple Startup Projects.

Co do implementacji, to uważam, że stosowanie serializacji/deserializacji w odniesieniu do całych pakietów, jak również parowanie typ CLR/rodzaj pakietu to nie są najszczęśliwsze decyzje ze względu na wersjonowanie, wydajność, interoperacyjność i możliwość ponownego wykorzystania kodu.

Problemy z wersjonowaniem mogłyby wystąpić, gdyby użytkownik łączący się z serwerem dysponował starszą wersją oprogramowania klienckiego. Ze względu na niezgodność lub brak definicji typów reprezentujących pakiety, zabawa z komunikatorem ograniczyłaby się u niego do łapania wyjątków, a jedynym pocieszeniem byłaby myśl, że w tym samym momencie krztusi się również serwer.

Kolejnym minusem przyjętego podejścia jest konieczność deserializacji każdego pakietu po stronie serwera. W efekcie tracimy czas procesora i pamięć na stworzenie grafu obiektów, z których część jest przydatna jedynie po stronie klienta. Z tym wiąże się jeszcze jeden efekt uboczny – każda alokacja pamięci na stercie zarządzanej to prowokowanie GC. Ponadto przy częstszym odśmiecaniu pamięci istnieje ryzyko, że więcej krótko żyjących obiektów będzie promowanych do starszych pokoleń. Z tych względów po stronie serwera powinniśmy unikać niepotrzebnych alokacji pamięci.

Odnośnie rozpoznawania rodzaju pakietu na podstawie typu CLR, to podejście takie ogranicza możliwość wielokrotnego wykorzystania kodu. Załóżmy, że nasz protokół wykorzystuje kilka rodzajów pakietów, które mają taką samą strukturę, a różnią się jedynie znaczeniem. Niestety nie możemy reprezentować ich z wykorzystaniem jednego typu. Musimy utworzyć typ bazowy, a na jego podstawie tyle pustych typów, ile mamy rodzajów pakietów.

Ponadto podejście takie niejako wymusza na nas użycie jakiegoś zastępstwa dla mechanizmu zdarzeń – u Ciebie padło na interfejs IMessageHandler i statyczną klasę MessageHandlerManager. Rozwiązanie to ma pewne wady, z których największą jest to, że handlery nie są związane z konkretną instancją serwera lub klienta, lecz z domeną aplikacji. W praktyce ogranicza to ilość takich instancji, jakie możemy utworzyć w programie, do jednej. Sensownym rozwiązaniem problemu byłoby stworzenie wspólnej klasy bazowej dla klienta i serwera. W ten sposób np. problem niestandardowego mechanizmu obsługi właściwości i zdarzeń rozwiązali twórcy WPF, wprowadzając klasę DependencyObject, z której wywodzą się tak pozornie odległe od siebie byty, jak pola tekstowe i przekształcenia liniowe z wykorzystaniem macierzy.

Dopracowania lub w zasadzie opracowania wymagałaby metoda konfiguracji serwera i klientów. Obecne rozwiązanie ze statyczną klasą Settings jest bardzo prowizoryczne. W zasadzie wystarczyłoby utworzyć właściwości Port i (u klienta) Host i skonsumować je w kodzie. (W przypadku serwera trzebaby jeszcze dodatkowo przenieść tworzenie instancji TcpListener do metody Start.) Klasa Settings mogłaby się przydać do zainicjalizowania tych właściwości z poziomu programów demonstracyjnych. Domyślam się, że obecne rozwiązanie wynika po prostu z lenistwa ;).

O ile wysyłanie wiadomości przez klienta odbywa się z wątku głównym, o tyle odbieranie wiadomości ma miejsce w wątku, w którym klient nasłuchuje informacji od serwera. Z obserwacji wiem, że posługiwanie się Invoke/BeginInvoke, a w szczególności zrozumienie potrzeby synchronicznego dostępu do interfejsu użytkownika sprawia problemy wielu osobom. Z tego względu warto zadbać, by wielowątkowa natura tworzonych przez nas klas była jedynie szczegółem implementacji, niewidocznym dla użytkownika końcowego. Szczególnie, że można to zrobić w zaledwie kliku liniach kodu. W klasie Client wystarczy zaimplementować metodę:

void HandleMessage(object message)
{
MessageHandlerManager.HandleMessage(this, (MessageBase) message);
}

a następnie w metodzie Connect, przed utworzeniem delegata threadStart, stworzyć zmienną:

AsyncOperation asyncOperation = AsyncOperationManager.CreateOperation(null);

i zastąpić wywołanie metody MessageHandlerManager.HandleMessage w następujący sposób:

asyncOperation.Post(HandleMessage, package.Message);

Gotowe. Klasa AsyncOperationManager "zatrzaskuje" w obiekcie AsyncOperation kontekst synchronizacji wątku, w którym została wykonana jej metoda CreateOperation. Następnie przy pomocy metody Post (nieblokującej – lub blokującej Send) możemy zlecać wykonanie kodu w tym wątku z poziomu innych wątków.

Według mnie nie należy odrzucać klasycznego podejścia przy implementacji protokołów komunikacji. Akurat "wielki switch" jest tylko narzędziem, faktycznie niezbyt subtelnym, natomiast podejście jest właściwe. Format pakietu mógłby wyglądać następująco:

|_Nagłówek_______________________________________________
|
| ID komunikatu (4 bajty)
| Długość wiadomości, bez nagłówka (4 bajty)
| Długość dodatkowej części nagłówka (4 bajty)
|
|_Wiadomość______________________________________________
|
| .
| .
| .

Serwer po otrzymaniu wiadomości:

1. Czyta nagłówek.
2. Zleca odnalezienie fabryki handlerów zdolnej do utworzenia handlera dla wiadomości określonego rodzaju:

IMessageHandlerFactory factory = MessageHandlerFactory.GetMessageHandlerFactory(header.MessageId);

3. Następuje poszukiwanie odpowiedniej fabryki – tu może znajdować się wielki switch, co jest złym rozwiązaniem, albo przeglądanie fabryk zarejestrowanych w kodzie lub w pliku konfiguracyjnym. Robi się z tego taki mini pojemnik IoC:

<apl.net>
<messageHandlerFactory defaultFactory="GenericMessageHandlerFactory">
<factories>
<clear />
<add name="LoginMessageHandlerFactory" messageId="1" type="Apl.Net.LoginMessageHandlerFactory" />
<add name="TextMessageHandlerFactory" messageId="2" type="Apl.Net.TextMessageHandlerFactory" />
.
.
.
<add name="GenericMessageHandlerFactory" type="Apl.Net.GenericMessageHandlerFactory" />
</factories>
</messageHandlerFactory>
</apl.net>

albo w ten sposób:

MessageHandlerFactory.Factories.Clear();
MessageHandlerFactory.Factories.Add(new LoginMessageHandlerFactory { MessageId = 1, Name = "LoginMessageHandlerFactory" });
MessageHandlerFactory.Factories.Add(new TextMessageHandlerFactory { MessageId = 2, Name = "TextMessageHandlerFactory" });
.
.
.
IMessageHandlerFactory defaultFactory = new GenericMessageHandlerFactory { Name = "GenericMessageHandlerFactory" };
MessageHandlerFactory.Factories.Add(defaultFactory);
MessageHandlerFactory.DefaultFactory = defaultFactory;

4. Jeśli została odnaleziona fabryka, jest tworzony i inicjalizowany handler wiadomości:

if (factory != null) {
// Pobierz wiadomość w postaci binarnej.
byte[] messageBits = … ;
IMessageHandler handler = factory.Create(this, header, messageBits);
handler.HandleMessage();
}
else {
// Odrzuć wiadomość.
…
}

To już wszystko. Handler może w ogóle nie wgłębiać się w treść wiadomości, tylko przesłać ją dalej. Postępowanie po stronie klienta powinno wyglądać analogicznie.

Jest to rozwiązanie podobne do Twojego w założeniach (modułowość, rozszerzalność itd.), ale:

1) serwer operuje wyłącznie na nagłówku pakietu – rodzaj wiadomości jest określany na podstawie pierwszych 4 bajtów, a nie na podstawie typu CLR,
2) protokół jest odporny na problemy z wersjonowaniem – nagłówek może zawierać dodatkowe informacje, które starsze wersje oprogramowania klienta mogą po prostu zignorować,
3) handler jest związany z konkretną instancją serwera lub klienta,
4) protokół nie opiera się na .NET-owej "magii" i może być z łatwością implementowany na innych platformach.

nie zostało nic do dopisania ;), apl wyczerpał temat, zostaje tylko kiwać głową i czekać na kolejny wpis na blogu ;)

@tom:
dzięki za uwagi, zamieszczając następnym razem coś nadającego się do działu Samples postaram się bardziej rozwinąć część tekstową

Romek, dzięki za komentarz, chociaż nie zgodzę się z Tobą :).

[i]Przy czym zaletą w rozwiązaniu Ayende jest wyeliminowanie rejestrowania poszczególnego MessageHandlera dlatego że jest on wyciągany z kontenera IOC.[/i]

Osobiście nie widzę różnicy. Wszystkie rozwiązania – moje, Procenta, Ayende – zakładają, że jest gdzieś jakiś statycznie dostępny pojemnik (ja nazywam go fabryką, Procent menadżerem, zaś Ayende pojemnikiem IoC), w którym najpierw rejestrujemy handlery (bezpośrednio lub pośrednio, przez fabryki), a następnie używamy go do znajdowania handlerów do obsługi konkretnych typów wiadomości. Ayende w zasadzie jedynie zautomatyzował sobie proces rejestrowania handlerów w pojemniku.

[i]Odnośnie wersjonowania zastanawia mnie sytuacja (…), gdzie dochodzi do zmiany interfejsu serwisu (…). Moim zdaniem nigdy do takiej sytuacji nie powinno dość. Wyjątkiem może być jedynie przypadek w którym serwis jest wykorzystywany tylko i wyłącznie przez nas(nawet wtedy bym się zastanawiał, gdzyż łamiemy kontrakt – możemy stworzyć nowy kontrakt ale starego nie powinniśmy ruszać).[/i]

Według mnie trochę zbyt teoretyzujesz w tym miejscu. Przede wszystkim wersjonowanie kontraktów nie jest takim znowu niespotykanym scenariuszem (np. w kontekście WCF – http://msdn2.microsoft.com/en-us/library/ms733832.aspx). Weźmy przykład: mamy serwer chat, Alicję i Roberta. Alicja posiada klienta w wersji 1.0, zaś Robert w wersji 2.0. W wersji 1.0 możliwe było jedynie wysyłanie prostych wiadomości tekstowych:

public class Message
{
   public string Text;
}

W wersji 2.0 pojawiła się możliwość wysyłania wiadomości HTML. Postanowiono nie zmieniać starego kontraktu, tylko utworzyć nowy:

public class Message2
{
   public string Text;
   public string HtmlText;
}

Robert chce wyłać wiadomość do Alicji:

– Klient Roberta wysyła wiadomość typu [i]Message2[/i],
– Serwer widzi, że wiadomość jest kierowana do Alicji i przesyła ją dalej,
– Klient Alicji odrzuca wiadomość, ponieważ nie znajduje handlera dla typu [i]Message2[/i].

Wiadomość jest odrzucana, pomimo że klient Alicji mógłby ją obsłużyć. Można próbować jakoś temu zaradzić, np. po zalogowaniu klient mógłby wysyłać komunikat z numerem wersji, wówczas serwer mógłby podjąć się zadania konwersji nowszych wiadomości do starszego typu. To niestety nie rozwiązuje problemu interoperacyjności – jeśli serwer przesyła nam zserializowane binarnie obiekty, jak zabrać się za pisanie alternatywnego klienta takiej sieci, nie dysponując orygialnymi definicjami typów?

[i]Nie jest jasne dla mnie jasne jaka jest potrzeba tworzenia fabryki fabryk MessageHandlerów :) (…) gdyż moim zdaniem nigdy nie powinno dochodzić do sytuacji gdzie jest wiele handlerów dla jednego typu wiadomości.[/i]

Ten mechanizm niekoniecznie musi być użyty w ten sposób (chociaż może, np. do zwracania różnych lub różnie skonfigurowanych handlerów zależnie od wersji protokołu, przy pomocy którego komunikuje się klient). Raczej chodzi o to, żeby rozwiązać problem handlerów-singletonów – singletonem jest w takiej sytuacji fabryka, która w zależności od potrzeb może tworzyć nowe obiekty handlerów, mogące przechowywać własny stan, lub zwracać zawsze tę samą instancję. Równie dobrze możnaby wykorzystać do tego celu pojemnik IoC i dla typów handlerów wymagających przechowywania stanu zdefiniować czas życia instancji jako [i]transient[/i], a dla pozostałych jako [i]singleton[/i]. Zaproponowałem takie rozwiązanie, gdyż jest z powodzeniem stosowane w ASP.NET – co warto podkreślić – na poziomie infrastruktury. Konkretnie mam na myśli obiekty implementujące interfejsy [i]IHttpHandler[/i] i [i]IHttpHandlerFactory[/i]. Do tworzenia instancji handlerów HTTP ASP.NET zawsze wykorzystuje fabryki. Twórcy umożliwili rejestrowanie w sekcji [i]httpHandlers[/i] pliku web.config typów wywodzących się nie tylko z [i]IHttpHandlerFactory[/i], lecz również z [i]IHttpHandler[/i], jednak pod maską wszystko, co nie jest fabryką, jest opakowywane w instancję klasy implementującej [i]IHttpHandlerFactory[/i].

[i]Nie jestem również zwolennikiem podejścia w którym MessageHandler tworzony jest na podstawie pliku konfiguracyjnego, ponieważ może to doprowadzić do problemów z zarządzaniem(należy się zastanowić czy jest potrzebna zmiana routowania message w wdrożonej aplikacji) i przede wszystkim komplikuje to testowaniu jednostkowe MessageHandlerFactory.[/i]

To akurat mało ważne. Zaproponowałem plik konfiguracyjny jako jedną z wielu metod rejestrowania własnych handlerów. Równie dobrze można np. klasy fabryk oznaczyć własnymi atrybutami i wrzucić pliki DLL do odpowiedniego folderu, z którego zostaną wczytane przez aplikację.