Engine.io или SockJS, какой из них выбрать?

У меня возникли проблемы с Socket.io в отношении утечек памяти и проблем с масштабированием в последнее время. Мое решение использовать Socket.io было сделано более года назад, когда это была, несомненно, лучшая библиотека для использования.

Теперь, когда Socket.io вызывает много проблем, я потратил время на поиск альтернатив, которые стали доступны в то же время, и думаю, что оба Engine.io и SockJS в целом хорошо подходят для меня. Однако, на мой взгляд, у обоих есть некоторые недостатки, и я не уверен, какой из них выбрать.

Engine.io - это в основном идеальная облегченная версия Socket.io, которая не содержит всех функций, которые мне не нужны. Я уже написал свою собственную логику повторного подключения и heartbeat для Socket.io, потому что меня не устраивали логики по умолчанию, и я никогда не собирался использовать комнаты или другие функции, которые предлагает Socket.io.

Но, по-моему, основным недостатком Engine.io является установление соединений. Клиенты начинают с более медленного jsonp-опроса и обновляются, если они поддерживают более качественный транспорт. Тот факт, что клиенты, которые поддерживают веб-сайты изначально (число, постоянно увеличивающееся), имеют недостаток в форме более длительной и нестойкой процедуры подключения по сравнению с теми клиентами, которые используют устаревшие браузеры, что противоречит моему пониманию того, как ее следует обрабатывать.

SockJS, с другой стороны, обрабатывает соединения точно так, как я хотел бы. Из того, что я прочитал, он выглядит довольно стабильным, в то время как у Engine.io есть некоторые проблемы в это время.

Мое приложение работает за маршрутизатором Nginx в одном домене, поэтому мне не нужны функции межсетевого домена, предлагаемые SockJS. Однако из-за предоставления этой функции SockJS вообще не раскрывает данные cookie клиента. До сих пор у меня было 2-факторное разрешение с Socket.io через токен строки cookie AND, и это было бы невозможно с SockJS (с Engine.io это было бы).

Я прочитал почти все то, что avilable, и плюсы и минусы обоих, но похоже, что пока мало что обсуждается или публикуется, особенно в Engine.io(есть только 8 вопросов, отмеченных с помощью engine.io здесь).

Какую из двух библиотек вы предпочитаете и по какой причине? Используете ли вы их в производстве?
Какой из них, вероятно, будет поддерживаться более активно и может иметь важное преимущество перед другим в будущем?

Ответ 1

Вы посмотрели Primus? Он предлагает требования к файлам cookie, которые вы упомянули, он поддерживает все доступные основные в режиме реального времени/доступные в Интернете библиотеки и представляет собой довольно активный проект. Для меня это также звучит как блокировка поставщика может быть проблемой для вас, и Primus обратится к этому.

Тот факт, что он использует плагиновую систему должен также a) облегчить вам расширение, если это необходимо, и b) может фактически иметь плагин сообщества, который уже делает то, что вам нужно.

Какую из двух библиотек вы предпочитаете и по какой причине? Используете ли вы их в производстве?

Я использовал SockJS только с помощью API Vert.x, и для внутреннего проекта я рассматривал бы "производство", но не продукт, ориентированный на потребительское приложение. Тем не менее, это было очень хорошо.

Какой из них, вероятно, будет поддерживаться более активно и может иметь важное преимущество перед другим в будущем?

Просто просмотрите историю фиксации Engine.io и SockJS, а также тот факт, что Auttomatic поддерживает Engine.io заставляют меня склонен думать, что это будет более стабильным, в течение более длительного периода времени, но, конечно, спорно. Рассматривая проблемы для Engine.io и SockJS это еще одно хорошее место для оценки, но поскольку они разделены на несколько репозиториев, их следует принимать с солью. Я не уверен, где/как Automattic использует Engine/Socket.io, но если он в WordPress.com или один из их плагинов, он имеет значительные испытания на битву на производстве.

изменить: изменить ответ, чтобы отразить поддержку cookie, подтвержденную автором Primus, в комментариях ниже

Ответ 2

Я хотел бы перенаправить вас на эту (довольно подробную) дискуссионную тему о SockJS и Engine.io

https://groups.google.com/forum/#!topic/sockjs/WSIdcY14ciI

В принципе,

SockJS обнаруживает рабочие транспорты перед маркировкой соединения как открытый. Engine.io немедленно откроет соединение и обновит это позже. flash, один из резервов Engine.io(и не присутствует в SockJS) загружается медленно и в средах за прокси-серверами занимает от 3 секунд до тайм-аута. SockJS не использует вспышку и, следовательно, не нужно работать этот вопрос.

SockJS выполняет обновление при запуске. После этого у вас есть последовательный опыт. Вы отправляете то, что вы отправляете, вы получаете что вы получаете.

Кроме того, насколько я могу судить, библиотека engine.io-client (клиентская) для engine.io не поддерживает сборки requirejs, так что другая отрицательная точка. (SockJS прекрасно работает).

Ответ 3

Вы также можете рассмотреть node-walve. Полный базовый WebSocket. Чрезвычайно эффективен как полностью потоковый.

Пример использования:

walve.createServer(function(wsocket) {
  wsocket.on('incoming', function(incoming) {
    incoming.pipe(process.stdout, { end: false });
  });
}).listen(server);

Это не лучший выбор, если вы не уверены в среде nodejs (например, распространяете прототипы для сахара API), внося свой вклад в проект (хотя код более читабельен как socket.io).