Иногда на проекте realtime уже нужен, а WebSocket по каким-то причинам нет. У нас сервер отдавал сообщения через long-polling (он же Comet): клиент шлёт «висящий» HTTP-запрос, сервер держит его открытым, пока не появятся новые сообщения, потом отвечает, а клиент тут же открывает следующий. На словах всё элементарно: бесконечный цикл из одного запроса.
Элементарно это ровно до первого запуска на живом устройстве где-нибудь в метро. Дальше вылезает всё то, ради чего я и сел писать эту статью: гонки при переподключении, дубли локальных пушей, два потока сообщений в одном ответе и пачка мелких состояний, которые надо аккуратно разруливать. Ниже разберу, как с этим жить, на примере iOS-сервиса (назову его LongPollChatService).
Сразу оговорюсь по всему дальнейшему коду: в сниппетах я опускаю синхронизацию, иначе идея размажется. В боевом сервисе всё изменяемое состояние long-poll цикла (currentRequestUUID, курсоры, счётчики, словарь отложенных задач) живёт на одном serial context. У меня это была отдельная очередь; в другом проекте мог бы быть actor или main thread. Без этого сам механизм защиты от гонок легко превращается в источник гонок, что было бы немного обидно)
Сам цикл: хвостовая рекурсия вместо while
WebSocket держит соединение, и события прилетают сами. С long-polling ты сам себе event loop: получил ответ - тут же запросил снова. В коде это не while, а хвостовая рекурсия: метод запроса при успехе вызывает сам себя.
private func requestNewMessages(token: ChatToken, requestUUID: String) {
apiManager.getMessages(token: token) { [weak self] response in
guard let self else { return }
guard self.currentRequestUUID == requestUUID else { return } // про это - ниже
switch response {
case .success(let messages):
self.handle(messages)
self.requestNewMessages(token: token, requestUUID: requestUUID) // снова в цикл
case .failure:
self.scheduleReconnect(token: token, requestUUID: requestUUID) // backoff
}
}
}
Полная цепочка старта чуть длиннее: сперва берём токен сессии, затем синхронизируем курсоры (про них пока ни слова, дойдём дальше), и только потом уходим в этот «висящий» запрос. Но сердцевина вот в этих двух строках: handle плюс повторный вызов себя.
Главная проблема: гонки при переподключении
А дальше начинается самое неприятное. Long-polling-запрос живёт долго: секунды, иногда десятки секунд. За это время может произойти что угодно - пользователь свернул приложение, сменил аккаунт, потерял сеть. Нам надо перезапустить цикл. Но старый-то запрос уже в полёте, и его колбэк всё равно прилетит, причём, возможно, уже после того, как мы всё перезапустили.
Ничего с этим не делать нельзя - получишь классику: два конкурирующих цикла, дубли сообщений, расползающиеся курсоры. А физически отменить сетевой запрос не всегда успеваешь: cancel() мог просто не догнать ответ.
Решение, которое мне зашло, - метка актуальности. У сервиса есть currentRequestUUID. Каждый старт цикла генерит новый UUID, и каждый колбэк первым делом сверяется: «а я ещё актуален?».
private var currentRequestUUID = ""
private func startNewCycle() {
let uuid = UUID().uuidString
currentRequestUUID = uuid // ставим новую метку - ещё до запроса токена
fetchToken { [weak self] token in
guard let self, self.currentRequestUUID == uuid else { return } // токен устарел - выходим
self.requestNewMessages(token: token, requestUUID: uuid)
}
}
// и так - в начале каждого колбэка по всей цепочке:
guard currentRequestUUID == requestUUID else { return } // я с устаревшей меткой → молча умираю
Идея простая: мы не пытаемся догнать и отменить всё, что уже в полёте. Вместо этого просто ставим метку актуальности, а устаревшее само себя глушит на входе в колбэк. stop() при этом обнуляет UUID целиком, и тогда вообще все летящие колбэки превращаются в no-op.
func stop() {
currentRequestUUID = "" // теперь ни один guard выше не пройдёт
requestsCount = 0 // сбрасываем счётчик активных циклов (про него - ниже)
chatTokenRequest?.cancelRequest()
messagesRequest?.cancelRequest()
deferredTasks.forEach { $0.value.cancel() }
deferredTasks.removeAll()
isEnabled = false
}
Поверх этого у меня живёт ещё один инвариант: активный цикл ровно один. Счётчик requestsCount при нормальной работе всегда 0 или 1, с ассертом в debug на случай, если вдруг стало больше.
guard requestsCount == 0 else { // активный цикл уже есть - второй не плодим
assertionFailure("должен быть ровно один активный long-poll")
return
}
requestsCount += 1
apiManager.getMessages(token: token) { [weak self] response in
guard let self else { return }
guard self.currentRequestUUID == requestUUID else { return } // устаревший колбэк - выходим
self.requestsCount -= 1 // слот освобождаем только за «свой» цикл
// ...обработка ответа...
}
Тут важна тонкость в порядке проверок: декремент стоит после сверки метки, а не в defer. И это не случайно. stop() сам обнуляет счётчик, поэтому устаревший колбэк, прилетевший уже после остановки, обязан выйти молча и счётчик не трогать - иначе увёл бы его в минус и заблокировал следующий старт. Правило короткое: requestsCount трогает только актуальный цикл, а stop() всегда возвращает его в ноль.
Если честно, вся эта проверка - скорее подстраховка от самого себя. UUID-токена в теории хватает, но реальный код обрастает ветками (смена аккаунта, ретраи, возврат сети), и проще иметь громкий ассерт, чем потом вылавливать второй невидимый цикл по логам. Меня она один раз уже выручила.
Backoff с джиттером
Если запрос упал, нельзя ломиться переподключаться сразу же и в цикле: при сетевом сбое все клиенты дружно заддосят сервер ровно в одну и ту же секунду. Нужен растущий интервал плюс случайный разброс (джиттер). И вот с джиттером легко промахнуться. Если взять растущую задержку и просто прибавлять-отнимать к ней пару случайных секунд (base ± random), клиенты всё равно собьются в кучу вокруг base, в узкой полосе. От той самой «толпы», что ломится переподключаться разом после сбоя сети, это спасает слабо.
Поэтому берут full jitter: задержка - это случайная точка по всему интервалу 0...cap, а не «где-то рядом с base». Так попытки размазываются равномерно, и синхронного всплеска на сервере не возникает. Сам интервал при этом растёт экспоненциально и упирается в потолок.
private let baseDelay: TimeInterval = 2 // стартовая задержка
private let maxDelay: TimeInterval = 30 // потолок
private var attemptCount = 0
private func reconnectInterval() -> TimeInterval {
defer { attemptCount += 1 }
let capped = min(baseDelay * pow(2, Double(attemptCount)), maxDelay) // 2, 4, 8, 16 … ≤ 30
return .random(in: 0...capped) // вся ширина интервала, не «около base»
}
После успешного ответа attemptCount сбрасывается в 0. Признаюсь, в проде у меня поначалу была версия попроще - ступенька с вычитанием случайных секунд. Full jitter - это ровно то, к чему стоило прийти сразу.
Жизненный цикл: фон, сеть, и кто кого будит
Long-polling нельзя оставлять висеть бесконечно. В фоне его всё равно прибьёт система, а открытый впустую запрос только зря держит соединение и сажает батарею. Поэтому цикл я жёстко привязал к состоянию приложения и сети.
Старт идёт, только если есть активная foreground-сцена.
func run() {
let isActive = UIApplication.shared.connectedScenes
.contains { $0.activationState == .foregroundActive }
if isActive { refresh() } else { stop() }
}
А возврат сети будит цикл сам, через подписку на reachability. С одной оговоркой: реагируем только на переход «не было → появилась», иначе на каждый чих коннективити-менеджера будем дёргать перезапуск.
var wasConnected = connectivity.isConnected
connectivity.addObserver(self) { [weak self] status in
switch status {
case .reachable where !wasConnected:
self?.requestNewMessages() // сеть вернулась - оживаем
wasConnected = true
case .unreachable:
wasConnected = false
default:
break
}
}
Отдельный слой - отложенные задачи, те самые ретраи с backoff. Это словарь [String: DispatchWorkItem]: каждая задача лежит по своему UUID-ключу и сама себя удаляет по завершении. Получается ручной планировщик поверх GCD. Не сказать что элегантно, зато stop() гасит всё одним проходом по словарю (см. выше).
Два потока сообщений в одном ответе
Защитить сам цикл от дублей - это только половина задачи. Вторая половина в том, что внутри одного ответа может ехать больше одного независимого потока событий, и у каждого свой курсор. У нас таких потоков было ровно два: сообщения приходят сразу для двух «личностей» пользователя - основного аккаунта и привязанного (второй профиль, который можно прицепить и отцепить). Ответ - словарь, где ключ это id пользователя, а значение - его сообщения.
// { "<основной userID>": [...], "<привязанный userID>": [...] }
messages.forEach { key, containers in
guard let userID = Int(key) else { return }
switch userID {
case primaryUserID:
parse(containers, cursor: &primaryCursor)
case linkedUserID:
parse(containers, cursor: &linkedCursor)
default:
assertionFailure("прилетел userID, которого мы не ждали")
}
}
У каждого потока свой курсор последнего полученного сообщения (primaryCursor / linkedCursor), и они независимы. А прямо в этой же ветке обрабатывается привязка-отвязка второго аккаунта: если в ответе с токеном вдруг появился id привязанного профиля, которого раньше не было, значит, аккаунт только что прицепили, дёргаем делегат. Если, наоборот, пропал - значит, отцепили, и надо вычистить из локальной БД все его чаты и обнулить курсор.
if let linkedID = tokenResponse.linkedUserID {
if linkedUserID != linkedID { // аккаунт только что привязали
delegate?.linkedAccountDidChange(userID: linkedID)
}
linkedUserID = linkedID
} else if linkedUserID != .invalid { // аккаунт отвязали
dbManager.deleteChats(forLinkedAccount: linkedUserID)
linkedUserID = .invalid
linkedCursor = nil
}
Магии тут никакой, но это как раз тот случай, когда «два» вместо «одного» протекает через весь сервис: два курсора, две ветки парсинга, два состояния. Если будете проектировать что-то похожее с нуля, закладывайте множественность потоков сразу - выйдет дешевле.
isFirstLoad: не задублировать пуши на старте
Тонкий продуктовый момент, который легко проворонить. Пока приложение лежало в фоне или было выгружено, сообщения копились, и на холодном старте мы вытягиваем весь этот хвост разом. Вопрос: показывать ли локальный пуш на каждое из них?
Нет. Пока приложение было в фоне, система уже показала по ним обычные remote-пуши. И если на старте мы добавим к ним ещё и локальные, пользователь увидит каждое сообщение дважды. А вот сообщения, которые прилетают уже при открытом приложении (когда remote-пуш не показывается), пушить локально как раз надо, иначе их в интерфейсе ничего не подсветит.
Значит, надо как-то отличить «догружаю накопившийся хвост» от «прилетело новое прямо сейчас». Для этого сравниваем максимальный id с сервера с локальным курсором.
// какой самый свежий id знает сервер на момент старта сессии
let serverMax = max(lastMessageInfo.primaryLastID, lastMessageInfo.linkedLastID ?? .invalid)
let localMax = max(primaryCursor, linkedCursor ?? .invalid)
// сервер ушёл вперёд → это накопившийся в фоне хвост, локальные пуши по нему НЕ шлём
isFirstLoad = serverMax > localMax
Пока isFirstLoad == true, мы догружаем хвост и молчим. Как только курсоры догнали серверный максимум, флаг гаснет, и дальше каждое новое сообщение уже идёт с локальным пушем. По сути пара строк, но именно они отвечают за то, что приложение не заваливает пользователя дублями уведомлений на каждый запуск.
Рассылка наблюдателям: чистка и доставка одним проходом
Сервис раздаёт сообщения наблюдателям (экранам). Держатся они слабыми ссылками, так что при каждой рассылке надо попутно выкидывать тех, кто уже умер (observer == nil). И тут я сознательно делаю и то, и другое за один проход, прямо внутри предиката removeAll(where:).
observers.removeAll { info in
guard info.observer.value != nil else { return true } // мёртвый → выпиливаем
if let messages = messages(for: info) {
DispatchQueue.main.async {
info.handler(messages) // живому - доставляем, в том же проходе
}
}
return false // живой остаётся в списке
}
Логика тут такая: мы всё равно идём по массиву, чтобы вычистить мёртвые ссылки, - так почему заодно не разослать сообщения тем, кто жив? Заводить ради этого второй отдельный forEach смысла мало: получится два прохода по тому же массиву там, где хватает одного. Да, формально это side-effect внутри предиката фильтрации, и тащить такой стиль повсюду я бы не стал. Но здесь он осознанный: массив наблюдателей маленький, а «почистить мёртвых и доставить живым» по смыслу одна операция.
Итого
Если оглянуться на весь сервис целиком, видно одну вещь: почти вся его сложность не про чаты как таковые, а про то, что long-polling по своей природе тащит за собой состояние. Висящий запрос живёт долго и переживает любое изменение вокруг себя - смену экрана, аккаунта, сети. Поэтому самым важным оказался не парсинг сообщений, а аккуратное обращение с этим «долгоживущим» запросом: метка актуальности, чтобы устаревшие колбэки гасли сами; инвариант на единственный активный цикл; и stop(), который честно подчищает за собой.
Три приёма, которые я заберу в любой следующий проект без сокетов:
UUID-метка актуальности - самый дешёвый способ обезвредить устаревшие колбэки, не воюя с гонкой отмены сетевого запроса. Ложится на что угодно: long-polling, SSE, да хоть серию обычных запросов.
сравнение курсоров для пушей - буквально пара строк, а избавляет от дублей нотификаций на холодном старте.
джиттер на backoff - становится обязательным ровно в тот момент, когда клиентов больше одного.
Со временем это, наверное, переехало бы на Swift Concurrency со структурированной отменой - тогда половина ручного жонглирования UUID’ами и счётчиками ушла бы внутрь Task и его cancellation, а serial context стал бы actor’ом. Но даже сейчас, без корутин, главная мысль не меняется: в realtime без сокетов отмену и переподключение надо закладывать с первого дня.