В этой главе мы обсудим резервные соединения, подключение с помощью Socket.IO, события и сообщения.
откаты
Socket.IO имеет множество базовых транспортных механизмов, которые имеют дело с различными ограничениями, возникающими из-за проблем с браузерами, реализаций WebSocket, брандмауэров, блокировки портов и т. Д.
Хотя W3C имеет определенную спецификацию для WebSocket API, он все еще не реализован. Socket.IO предоставляет нам запасные механизмы, которые могут справиться с такими проблемами. Если мы разрабатываем приложения с использованием нативного API, мы должны сами реализовать запасные варианты. Socket.IO охватывает большой список запасных вариантов в следующем порядке:
- WebSockets
- FlashSocket
- XHR длинный опрос
- XHR многочастная потоковая передача
- XHR опрос
- JSONP опрос
- плавающие фреймы
Подключение через Socket.IO
Соединение Socket.IO начинается с рукопожатия. Это делает рукопожатие особой частью протокола. Помимо рукопожатия, все другие события и сообщения в протоколе передаются через сокет.
Socket.IO предназначен для использования с веб-приложениями, и поэтому предполагается, что эти приложения всегда смогут использовать HTTP. Именно по этой причине рукопожатие Socket.IO происходит по HTTP с использованием запроса POST на URI рукопожатия (передается в метод connect).
События и сообщения
Собственный API WebSocket отправляет только сообщения. Socket.IO предоставляет дополнительный слой над этими сообщениями, который позволяет нам создавать события и снова помогает нам легко разрабатывать приложения, разделяя различные типы отправляемых сообщений.
Собственный API отправляет сообщения только в виде простого текста. Об этом также заботится Socket.IO. Он обрабатывает сериализацию и десериализацию данных для нас.
У нас есть официальный клиентский API для Интернета. Для других клиентов, таких как собственные мобильные телефоны, другие клиенты приложений, мы также можем использовать Socket.IO, выполнив следующие шаги.
Шаг 1 — Соединение должно быть установлено с использованием того же протокола соединения, который обсуждался выше.
Шаг 2 — Сообщения должны быть в том же формате, который указан Socket.IO. Этот формат позволяет Socket.IO определять тип сообщения и данные, отправляемые в сообщении, а также некоторые метаданные, полезные для работы.
Формат сообщения —
[type] : [id ('+')] : [endpoint] (: [data]
Параметры в приведенной выше команде объяснены ниже —
-
Тип представляет собой однозначное целое число, определяющее тип сообщения.
-
ID — это идентификатор сообщения, инкрементное целое число, используемое для подтверждений.
-
Конечная точка — это конечная точка сокета, которой сообщение предназначено для доставки …
-
Данные — это связанные данные, которые будут доставлены в сокет. В случае сообщений он обрабатывается как обычный текст, для других событий он обрабатывается как JSON.
Тип представляет собой однозначное целое число, определяющее тип сообщения.
ID — это идентификатор сообщения, инкрементное целое число, используемое для подтверждений.
Конечная точка — это конечная точка сокета, которой сообщение предназначено для доставки …
Данные — это связанные данные, которые будут доставлены в сокет. В случае сообщений он обрабатывается как обычный текст, для других событий он обрабатывается как JSON.
В следующей главе мы напишем приложение для чата в Socket.IO.