WebSocket Interface
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)
1 – CONNECTING – połączenie nie zostało jeszcze zrealizowane,
2 – OPEN – połączenie zostało zrealizowane i możliwa jest komunikacja z serwerem,
3 – CLOSING – połączenie jest w trakcie rozłączania,
4 – 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.
)
