Бывает так, что 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 без сокетов отмену и переподключение надо закладывать с первого дня, а не после первого бага в метро. Всё остальное — детали)