Flutter + Socket.io — Обмен информацией в режиме реального времени

[symbix]

'transports': ['websocket'],

Наверное, в большинстве случаев не стоит так делать. Одно из важных преимуществ socket.io - умение работать в режиме поллинга. По дефолту он начнёт с поллинга и сразу же попытается проапгрейдиться на вебсокеты, а если не судьба - что же останемся на поллинге (автокоррект предлагает «пол-литре», что ж, тоже вариант).

По моему опыту, где-то у одного процента пользователей вебсокеты по тем или иным причинам (обычно какая-нибудь суровая корпоративная прокси) не работают.

[nowm]

У socket.io можно в процессе работы вернуть поллинг. То есть, он инициализируется только с websocket, но если соединение несколько раз сфейлилось, поллинг включается. Это не стандартная фишка socket.io, а кастомный код. Упрощённо (для версии 2.3), выглядит примерно так:

let reconnectionAttempt = 0;

const socket = io('server_name', {transports: ['websocket']});

socket.on('reconnect_attempt', () => {
  reconnectionAttempt++;

  if (reconnectionAttempt > 2) {
    socket.io.opts.transports = ['polling', 'websocket'];
  }
});

Опять же, повторюсь, это упрощённый подход, который я вытащил из одного из старых проектов, и самый важный код здесь: socket.io.opts.transports = ['polling', 'websocket']; — когда список доступных транспортов меняется уже после инициализации.

Просто когда поллинг включён с самого начала, при установке соединения делается несколько HTTP-запросов, которые дают лишнюю нагрузку. Если клиентов реально много, это не помогает делать сервис быстрым.

У того одного процента пользователей, которые не могут использовать транспорт websocket, в такой ситуации просто будет немного дольше устанавливаться соединение, потому что требуется время на то, чтобы понять, что нужно включить поддержку поллинга. У остальных 99% пользователей соединение будет устанавливаться на порядок быстрее, потому что во время инициализации не будет делаться 2 предварительных полл-запроса перед установкой websocket-соединения (во всяком случае, мне помнится так, что при включённом во время инициализации поллинге сначала делается 2 полл-запроса и только потом делается нормальное websocket-соединение).

Если бы я делал сейчас, я бы сделал немного по-другому, но основной мотив бы оставил: инициализация с только websocket и включение поллинга, если он реально требуется (в коде выше просто могут появиться ложные срабатывания из-за его логики). Эта маленькая фишка экономит очень много ресурсов — особенно когда на сайте много посетителей.

[symbix]

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

Но опускать этот код и просто приводить в примере transport: websockets некорректно, люди же накопипастят, а потом будут удивляться проблемам. Для короткого примера лучше оставить дефолты.

[aleks_raiden]

А разве не то же самое, если изначально просто поменять местами транспорты - transports = ['websocket','polling'] ?