Чаты на вебсокетах в iOS, если у вас WAMP

Разработка заняла примерно 9 месяцев, а я занимался реализацией клиент-серверного общения по сокету для iOS. Особенности нашей ситуации:

1. Поддержка старых версий iOS, где нативных методов для общения по сокетам ещё не было — пришлось искать рабочую библиотеку и фиксить баги.
2. Протокол WAMP на бэкенде — предстояло научить клиент декодировать any, декодировать протоколы и создать объект, который отвечает за отправку и приём сообщений.

Примечание: описанные ниже способы декодирования, можно применить и в других задачах.

Поиск живой библиотеки

Нативные методы для работы с вебсокетами были еще в iOS 11, а с версии iOS 13 они стали даже удобными. Но мы хотели сделать рабочий чат для всех с версии iOS 9, а уже потом потихоньку убирать поддержку. На это было несколько причин, в том числе и то, что у наших пользователей в США довольно много старых версий операционной системы.

Писать поддержку вебсокетов, начиная с iOS 9, самостоятельно было бы слишком долго, поэтому решил искать готовую библиотеку. Выбирал по популярности и количеству заведённых тикетов, в итоге остановился на Starscream. Но и она оказалась с проблемами — у библиотеки до сих пор висят десятки открытых тикетов и, по сравнению с нативным решением в iOS 13, она очень объёмная.

Смотрел ещё в сторону Socket.IO — самую большую из конкурентов — там меньше форков и лайков, но при этом в несколько раз больше незакрытых вопросов.

Starscream, в свою очередь, вызывала баги, и её пришлось форкать. Вот две основные проблемы, с которыми мы столкнулись (они обнаружились не сразу, а только в процессе тестирования, когда появилось больше данных):

1. Отсутствие события на таймаут. Из-за этого были сложности с переподключением к сокету после восстановления интернет-соединения.
2. Неверные очереди вызова коллбеков.

Ещё несколько багов:

• Коллбек не получал ошибку в ряде случаев.
• В некоторых местах был возврат функций без вызова коллбека по неизвестной причине.
• Ошибка компиляции на XCode 12. Прямо в процессе разработки вышел новый XCode, а библиотека не обновилась. Мы немного подождали, но в итоге пришлось фиксить самостоятельно каст к NSString.

Работа с WAMP

Как отправлять и получать данные было понятно, и пошла более высокоуровневая работа. Бэкенд выбрал протокол общения клиента с сервером WAMP, но для клиента он не работает из коробки, пришлось допиливать.

Минусы протокола:

– Кодирование всех типов событий в числах (PUBLISH — это 16, SUBSCRIBE — 32 и так далее), что сильно усложняет чтение логов для разработки и QA (пойди, сразу догадайся, что значит прилетевшее сообщение [33,11,5862354]).

– Механизм подписок на события (например, новые сообщения в чат или обновление количества участников) реализован через получение от бэкенда уникального id подписки, который ещё надо где-то хранить и ни в коем случае не терять во избежание утечек.

Плюсы:

+ Радует, что протокол за вас предусматривает всё или почти всё. Это облегчает взаимодействие разработчиков клиентской части и бэкенда.

Чтобы довести его до ума, передо мной стояли три основные задачи:

1. Научиться кодировать и декодировать any. У нас клиент-серверное общение в JSON-формате и сервер присылает/получает сообщения, которые стандартно не декодируются.
2. Кодировать и декодировать протоколы.
3. Создать объект, который будет отвечать за отправку и приём сообщений.

Первые два пункта в большей мере описывают способы декодирования, которые, можно применить в других задачах.

Рассмотрим на примерах. Допустим, мы получаем от сервера сообщение:

[36, 1, 2, {}]

Расшифровываем согласно этому документу и получаем:

[EVENT, SUBSCRIBED.Subscription|id, PUBLISHED.Publication|id, Details|dict]

Как декодировать

Сначала преобразуем JSON в [Any], для этого написано расширение для UnkeyedDecodingContainer. Так выглядит использование:

var container = try decoder.unkeyedContainer() var array = try container.decode([Any].self)

Из массива нужно убрать первый элемент, определить по нему тип сообщения (в данном случае это EventMessage) и преобразовать его в decoder для декодирования уже готовым инициализатором протокола Decodable.

Первый элемент массива всегда является числом, которое нужно связать с конкретным типом сообщения. Так выглядит enum для связи числа и типа:

enum WampMessageDecodableType: Int, Decodable, CaseIterable {     case event = 36          private var messageType: WampMessageDecodable.Type {         switch self {         case .event: return EventMessage.self         }     }          var factory: (Decoder) throws -> WampMessageDecodable {         messageType.init(from:)     } }

Преобразуем число в соответствующий ему тип:

guard let typeValue = array.removeFirst() as? Int,               let messageType = WampMessageDecodableType(rawValue: typeValue)         else { throw Self.typeDecodingError }

Так как у массива нет ключей, а типы в нём разные, нужно преобразовать его в словарь, где ключом будет являться его индекс:

let data = try JSONSerialization.data(withJSONObject: array.indexToKeyDictionary)

Где indexToKeyDictionary кастомное расширение. Результат:

[1, 2, {}] => {0: 1, 1: 2,  3: {}}

Опишем расширение и структуру для получения декодера из Data:

struct DecoderHolder: Decodable {     let decoder: Decoder      init(from decoder: Decoder) throws {         self.decoder = decoder     } }   extension JSONDecoder {     func getDecoder(from data: Data) throws -> Decoder {         try decode(DecoderHolder.self, from: data).decoder     } }

Теперь получаем декодер и декодируем сообщение:

let keyDecoder = try JSONDecoder.defaultDecoder.getDecoder(from: data) message = try messageType.factory(keyDecoder)

Чтобы декодирование работало с целочисленными ключами, используем CodingKeys с типом Int и расширение:

extension CodingKey where Self: RawRepresentable, RawValue == Int {     var stringValue: String {         .init(intValue ?? .min)     } }

Теперь сообщения можно декодировать стандартным декодером и не описывать дополнительный маппинг. Так, например, выглядит WelcomeMessage:

struct WelcomeMessage: WampMessageDecodable {     let sessionId: Int     let details: WelcomeDetails          enum CodingKeys: Int, CodingKey {         case sessionId, details     } }

C EventMessage немного сложнее, так как внутри он также содержит протокол. Декодируем его через вспомогательную структуру:

struct TypeHolder<T: Decodable>: Decodable {     let type: T }

Так выглядит упрощённый EventMessage:

public protocol EventEntry: Decodable { }  struct EventMessage: WampMessageDecodable, SubscriptionIdProvidable {     let event: EventEntry          enum CodingKeys: Int, CodingKey {         case event     }          init(from decoder: Decoder) throws {         let container = try decoder.container(keyedBy: CodingKeys.self)         let superDecoder = try container.superDecoder(forKey: .event)         let typeHolder: TypeHolder<EventMessageType> = try container.decode(forKey: .event)         event = try typeHolder.type.factory(superDecoder)     } }

Где EventMessageType аналогичен WampMessageDecodableType:

enum EventMessageType: Int, Codable, CaseIterable {     case chatListUpdate = 100          private var messageType: EventEntry.Type {         switch self {         case .chatListUpdate: return ChatListUpdateEventEntry.self         }     }          var factory: (Decoder) throws -> EventEntry {         messageType.init(from:)     } }

Рассмотрим ещё один пример декодирования ResultMessage. Так выглядит сообщение:

[50, 7814135, {}, [], {"userid": 123, "karma": 10}]

Сложность в том, что ResultMessage не может быть дженериком, так как тип ответа неизвестен заранее, и в зависимости от конкретного запроса возвращаемое значение (объект по третьему индексу) будет отличаться.

Решение состоит в том, чтобы сохранить декодер и использовать его позже, когда тип будет определён.

struct ResultMessage: WampMessageDecodable, RequestIdProvidable {     private var resultDecoder: Decoder          enum CodingKeys: Int, CodingKey {         case resultDecoder = 3     }          init(from decoder: Decoder) throws {         let container = try decoder.container(keyedBy: CodingKeys.self)         resultDecoder = try container.superDecoder(forKey: .resultDecoder)     } }  extension ResultMessage {     func decodeResult<T: Decodable>() throws -> T {         try T.init(from: resultDecoder)     } }

Кодирование происходит по схожим принципам и отличается незначительно.

Общение с сокетом

Объект WebsocketSessionImpl инкапсулирует в себе создание и разрыв соединения с сокетом, менеджмент получения и отправку сообщений, а также держит массив делегатов со слабыми ссылками. Когда делегаты деинициализируются, то соединение с сокетом закрывается с небольшой задержкой.

Подключение к сокету достаточно простое. Получаем handshake от первого делегата и коннектимся:

guard let request = firstDelegate?.handshakeRequest else { return }  socket = .init(request: request) socket?.delegate = self socket?.connect()

WebsocketSessionImpl сохраняет коллбеки запросов для ивентов и подписок. И вызывает их при получении ответа.

Так выглядят сигнатуры главных методов общение с WebsocketSessionImpl:

func call<T: CallRequest>(     request: T,     completion: @escaping (Result<T.ResultType, Error>) -> Void ) func subscribe<T: EventRequest>(     request: T,     completion: @escaping (Result<UUID, Error>) -> Void,     onEvent: @escaping (Result<T.ResultType, Error>) -> Void ) func unsubscribe(     id: UUID,     completion: @escaping (Result<Void, Error>) -> Void ) func publish<T: PublishRequest>(     request: T,     completion: @escaping (Result<Void, Error>) -> Void )

Call — похож на get-запрос; publish — это post; subscribe — подписка на событие (например, получение нового сообщение из чата); unsubscribe — отписка от события. Результатом всех этих методов является инициализация сообщения определённого типа и отправка его в JSON-формате.

При этом коллбеки под обёрткой сохраняются в словарь и ожидают ответа:

private var results: [RequestId: SaveableCompletion] = [:]

Аналогично для событий:

private var events: [SubscriptionEvent: SaveableCompletion] = [:]

Подписка только одна, а внутри приложения разные модули могут подписываться на одно и то же событие. Поэтому при наличии подписки создается её копия с другим коллбеком:

private struct SubscriptionEvent: Hashable {     let id: Int     let localId = UUID()     let topic: TopicModel          func copy() -> Self {         .init(id: id, topic: topic)     } }

При получении текста из сокета, вызывается метод:

func handleText(_ text: String) {     let data = try text.data(using: .utf8)     let message = try JSONDecoder.defaultDecoder.decode(WampBaseDecodableMessage.self, from: data).message     handleMessage(message) }

Затем сообщение (в зависимости от типа) обрабатывается:

func handleMessage(_ message: WampMessageDecodable) {     switch message {     case _ as ChallengeMessage:         sendAuthenticateMessage()     case _ as WelcomeMessage:         isConnected = true     case let message as ErrorMessage:         handleErrorMessage(message)     case let message as RequestIdProvidable & WampMessageDecodable:         informThatRecieved(message)     case let message as SubscriptionIdProvidable & WampMessageDecodable:         informSubscriber(message)     default:         break     } }

В качестве примера, отправка publish-сообщения:

public func publish<T: PublishRequest>(request: T, completion: @escaping (Result<Void, Error>) -> Void) {     let id = nextId     results[id] = .init(respondTo: PublishedMessage.self, completion)     let message = factory.publish(requestId: id, request: request)     write(message: message, with: completion) }   func write<T>(message: WampMessageEncodable, with completion: @escaping (Result<T, Error>) -> Void)  {         do {         try writeToSocket(message: message, with: { error in             guard let error = error else { return }             completion(.failure(error))         })     } catch let error {         completion(.failure(error))     } }  func writeToSocket(message: WampMessageEncodable, with completion: ((Error?) -> Void)?) throws {     let baseMessage = try WampBaseEncodableMessage(message:message)     let data = try JSONEncoder.defaultEncoder.encode(baseMessage)          guard let text = String(data: data, encoding: .utf8)     else { return }          socket?.write(string: text, completion: completion) }

Вместо заключения

Остальная реализация чата — это отдельная история, логика во многом переписывалась, а UI уже был написан, но всё это не касается сокета. Что же касается реализации клиент-серверного общения на Android с учетом WAMP — об этом в другой раз.