Jedną z ciekawszych nowinek, które mają być wprowadzone wraz ze standardem HTML 5 jest (a może „są”…) WebSockets.
To do czego WebSockets mają służyć idzie opisać jednym zdaniem:
” Strony internetowe za pomocą protokołu WebSockets mogą nawiązać DWUSTRONNE połączenie ze zdalnym serwerem.”
Do tej pory, komunikacja była jednostronna. Ze strony zostało wysyłane zapytanie i serwer zwracał odpowiedź. Wprowadzenie technologii AJAX zautomatyzowało trochę ten proces, uruchomiony w przeglądarce javascript automatycznie wysyłał zapytanie i obsługiwał nadesłaną odpowiedź. Mimo iż to przypomina dwustronną komunikację – nadal jest ona jednostronna.
Czasami takie zapytania są powtarzane w bardzo krótkich okresach czasu (20-30 sekund) – nazywa się to HeartBeating (bicie serca). Główny problem jednak pozostaje taki sam: generowane jest wiele zapytań, które serwer musi obsłużyć. Na szczęście AJAX pozwala na minimalizację pytania i aktualizację tylko części strony, a nie pobieranie całej strony co kilkadziesiąt sekund, jednak problem pozostaje problemem.
Wspomniany wyżej protokół rozwiązuje ten problem poprzez wykorzystanie komunikacji dwustronnej. Ma ty wyglądać w ten sposób, że przeglądarka nawiązuje połączenie ze zdalnym hostem, a gdy informacje na tym hoście się zmienią zostaną wysłane z powrotem do przeglądarki. Nie trzeba już odpytywać serwera o zmiany co kilkadziesiąt sekund.
Z punktu widzenia użytkownika nic się nie zmieni, jednak z punktu widzienia developera bardzo dużo: wydajność, prostota użycia to główne zalety tego rozwiązania.
Trochę bardziej techniczniej
Konstruktor otwieranego obiektu WebSocket posiada dwa elementy:
- pierwszym z nich jest URL z jaki należy się połączyć,
- drugi to protokół, który ma być użyty do komunikacji.
Jeżeli występują jakieś błędy, np. URL jest nieprawidłowy lub użyto w nim niedozwolonych znaków, port jest zablokowany, protokół nie obsługiwany to serwer zwróci błąd. W przeciwnym przypadku jest generowany nowy obiekt WebSocket.
Z obiektem tym komunikujemy się za pomocą poniższych metod:
- url – zwraca nam url połączenia użyty w konstruktorze,
- readyState – zwraca nam stan połączenia, który może przyjać jedną z poniższych wartości:
(wartości te są numeryczne, dodatkowo podaję ich tekstowy odpowiednik)
- CONNECTING – połączenie nie zostało jeszcze zrealizowane,
- OPEN – połączenie zostało zrealizowane i możliwa jest komunikacja z serwerem,
- CLOSING – połączenie jest w trakcie rozłączania,
- CLOSED – połączenie zostało zamknięte lub nie zostało otworzone.
W momencie utworzenia obiektu status musi być zmieniony na CONNECTING
.
W celu przesłania danych używamy metody send(data)
. W rezultacie wywołania tej metody uzyskamy wartość boolean
oznaczającą czy wysyłka była pomyślna czy nie.
Wysyłane dane, są bufforowane po stronie serwera. Wielkośc tego buffera można sprawdzić za pomocą metody bufferedAmount
. Sprawdzanie tego bufera jest przydatne zwłaszcza przy wykorzystaniu połączeń asynchronicznych – gdzie jedno połączenie wysyła dane, a drugie pobiera obliczenia na podstawie tych danych. W przypadku, gdy zostanie wysłane zapytanie o rezultat a nie wszystkie dane zostaną już przesłane to rezultat ten może być błędny. Warto zatem opatrzeć tą metodę sprawdzeniem czy bufferedAmount
jest równe 0 co oznacza że wszystkie dane są już wysłane.
WebSockets muszą także implementować kilka rodzajów zdarzeń na które muszą reagować:
Zdarzenia które występują to: open
, close
, message
i error
, natomiast metody nasłuchujące wystąpienia tych zdarzeń to :onopen
, onclose
, onmessage
i onerror
.
Resume
Jeżeli kogoś interesuje bardziej temat polecam wgłębienie się w API tego ciekawego protokołu, który IMO może przynieść kolejną rewolucję w internecie. Na dzień dzisiejszy jednak nie jest on do końca wspierany przez wszystkie przeglądarki. Pomimo, że Chrome, Safari i Firefox implementują go w mniejszej lub większej skali, to pozostaje jeszcze najpopularniejsza przegląrka – Internet Explorer, która nie implementuje tej funkcjonalności wogóle. Mam nadzieję, że to się zmieni.
.