Я читаю документацию Socket.io в разделе Использование нескольких узлов : https://socket.io/docs/using-multiple-nodes/
В нем упоминается в начале о том, что для соединения по умолчанию Long-polling (которое затем можно обновить до Websocket) необходимо, чтобы его запрос был связан с определенным идентификатором сеанса, подключенным к процессу, который его инициировал. В противном случае вы получите ошибку 400 Error during WebSocket handshake.
Затем упоминается, что у веб-сокетов нет этой проблемы из-за того, что базовое TCP-соединение остается открытым. Затем он предлагает вариант использования только транспорта websocket, но НЕТ ОТКАЗА от длительного опроса, когда соединение через веб-сокет не может быть установлено:
const client = io('https://io.yourhost.com', {
// WARNING: in that case, there is no fallback to long-polling
transports: [ 'websocket' ] // or [ 'websocket', 'polling' ], which is the same thing
})
1 - Для меня проблема с этой документацией заключается в что теперь я не понимаю, какое решение дает лучшую производительность / результаты. Поскольку у меня нет опыта, я подумал, что выложу этот topi c здесь, чтобы получить представление от разработчиков, имеющих опыт реализации этого, какой подход, который вы реализовали, который, по вашему мнению, лучше всего подходит для вас? Т.е. только веб-сокет или длительный опрос по умолчанию (обновление до веб-сокетов), но использовать липкий сеанс в процессе?
2- Также упоминается следующее:
Для достижения липкого -session существует два основных решения:
Опять же, я был бы признателен, если бы получил некоторую информацию от любого, у кого есть опыт в отношении того, какая реализация дала лучшую производительность или просто она сработала для вас лучше и почему.
Заранее большое спасибо