Minęły już prawie dwa miesiące odkąd powstał mój ostatni wpis na tym blogu. Pomimo wielkiej chęci powrotu do tworzenia nowych treści, poległem. Na ten stan rzeczy złożyło się wiele spraw w pracy oraz życiu osobistym. Jednak wracam i mam nadzieję, że już na dobre. Chciałbym wytrwać przy rutynie, którą kiedyś miałem i dostarczać świeże artykuły raz na tydzień. I tego się trzymajmy.
A co dzisiaj wziałem na tapet? Prawie rok temu popełniłem wpis na StackOverflow z pytaniem dotyczącym pobierania danych z zewnętrznego serwera w krótkich przedziałach czasowych. Z tym problemem spotkałem się podczas implementacji aplikacji BarentsWatch. Prowadząc dyskusję z użytkownikiem Sergio Tulentsev padły terminy Short i Long Pollingu. Wydały mi się one wtedy interesujące i chciałbym Ci je dzisiaj przybliżyć. Dokładniej ujmując, przedstawię czym różnią się pomiędzy sobą Short Polling, Long Polling oraz dodatkowo WebSocket.
Czym w ogóle jest Polling?
Polling to technika polegająca na pozyskiwaniu danych od dostawcy poprzez wykonywanie zapytań do jego API w regularnych odstępach czasu. Służy to głównie do odświeżania posiadanych informacji sprawiając wrażenie jakby aktualizowały sie one w czasie rzeczywistym. Wiele aplikacji korzysta z tego konceptu, w tym właśnie mój mały projekt BarentsWatch.
Koncepcja Short Polling
Skoro już mamy wspólną definicję co do Pollingu to przejdźmy do jego pierwszej “implementacji” jaką jest Short Polling. Polega ona na odpytywaniu serwera w regularnych odstępach i w przypadku kiedy serwer posiada dane to nam je zwróci, a jeśli nie to przekaże pustą wiadomość. Jeśli więc nie dostaniemy niezbędnej nam informacji to ponawiamy nasze zapytanie aż do skutku. Widać od razu jaki problem to implikuje. Dla każdego zapytania zużywamy cenne zasoby na:
- ustanowienie połączenia
- przeprocesowanie headera
- odpytanie o to czy dane faktycznie są gotowe na serwerze
- utworzenie odpowiedzi (nawet jeśli jest pusta)
- zamknięcie połączenia
- posprzątanie po sobie
Dobrą analogią do tego mechanizmu jest słynna scena z filmu Shrek 2. Osioł z nudów ciągle wypytywał Shreka o to czy “Daleko jeszcze?”. A jak wszyscy dobrze pamiętamy to “cenne zasoby” u ogra się szybko wyczerpały. Zatem czy jest jakieś wyjście z tej sytuacji? Pewnie, że tak.
Koncepcja Long Polling
Odpowiedzią na powyższy problem jest Long Polling. Procedura wygląda następująco. Klient wysyła żądanie do serwera, ale on mu nie odpowie pustą wiadomością. Będzie trzymał połączenie aż do czasu, gdy dane dla klienta będą gotowe do zwrócenia. Następnie te kroki powtórzą się z racji tego, że aplikacja, jak było wspomniane wcześniej, ma sprawiać wrażenie działania w czasie rzeczywistym. Dzięki takiemu podejściu nie trzeba tak często stabilizować nowych połączeń.
Oczywiście nie ma nic za darmo. Wtedy to jedno połączenie z puli połączeń jest niedostępne dla innych klientów. Dodatkowo jeśli dane nie będą długo zwracane może dojść do timeoutu. Z tego powodu warto przemyśleć również ten scenariusz przy wykorzystaniu Long Pollingu.
Tą koncepcję można porównać do składania zamówienia w restauracji. Wybieramy danie dla siebie, opłacamy i czekamy aż nasz posiłek zostanie wydany. Nie chodzimy i nie ponawiamy prośby o jego otrzymanie (chyba, że faktycznie będzie trwało to zbyt długo, ale powiedzmy, że wtedy nasza cierpliwość to taki timeout).
Różnica koncepcyjna pomiędzy Short Polling a Long Polling
No dobra, a czy jest dostępne jeszcze inne rozwiązanie? A jakże by inaczej!
Koncepcja WebSocket
WebSocket to protokół komunikacyjny, który pozwala na dwukierunkową wymianę danych pomiędzy klientem a dostawcą przy pomocy połączenia TCP. Aby uzyskać taki efekt połączenie pomiędzy dwoma stronami jest ciągle otwarte. W ten sposób można powiedzieć, że klient prowadzi konwersację z serwerem, ponieważ obydwoje mogą wysyłać informacje drugiej stronie.
Widać, że ten koncept idealnie nadaje się do aplikacji potrzebujących danych w czasie rzeczywistym. Jedną z rzeczy jaką trzeba brać pod uwagę stosując WebSocket jest to, że starsze przeglądarki mogą nie wspierać tego typu rozwiązania. Na szczęście takich przypadków jest coraz mniej.
Zatem dlaczego nie powinno się zawsze korzystać z WebSocket? Jak zawsze zależy to od kontekstu. Być może nasza aplikacja nie będzie chciała blokować każdego połączenia na stałe. Dodatkowo inne rozwiązanie jak Long Polling prawdopodobnie okaże się korzystniejsze przy nagle wzrastającym ruchu użytkowników.
WebSocket sprawdza się najbardziej w specyficznych przypadkach, gdzie czas oczekiania na odpowiedź musi być naprawdę niski. Dobrym przykładem zastosowania będą czaty na żywo, streamowanie mediów czy sieciowe gry multiplayer.
Podsumowanie
Na koniec w ogóle nie wspominałem już o Short Pollingu. Dlaczego? Ponieważ na każdej stronie z materiałami, które znalazłem, to podejście nie jest nigdy zalecane. Natomiast Long Polling oraz WebSocket już jak najbardziej. Warto, więc te wszystkie podejścia znać i wiedzieć, które kiedy stosować, a których unikać jak ognia.
Naprawdę dobrze jest wrócić do pisania. Jak pisałem na wstępie, mam nadzieję, że to znowu będzie moją rutyną. Także zakasuję rękawy i do następnego wpisu!