Engine.io或SockJS,哪一个可供选择？

我最近遇到了关于内存泄漏和扩展问题的Socket.io问题.我决定使用Socket.io是在一年前做出来的,当时它无疑是最好的库.

既然Socket.io造成了很多麻烦,我花时间寻找在此期间可用的替代品,并认为Engine.io和SockJS通常都适合我.但是,在我看来,两者都有一些缺点,我不确定选择哪一个.

Engine.io基本上是Socket.io的完美轻量级版本,它不包含我不需要的所有功能.我已经为Socket.io编写了自己的重新连接和心跳逻辑,因为我对默认逻辑不满意,我从不打算使用Socket.io提供的房间或其他功能.

但是 - 在我看来 - Engine.io的主要缺点是建立连接的方式.客户端以较慢的jsonp-polling开始,如果它们支持更好的传输,则会升级.该支持WebSockets的原生(数量不断增加)的客户有超过那些使用过时的浏览器客户更长的和不稳定的连接过程的形式不利的事实,违背我的,应该如何处理的感觉.

另一方面,SockJS完全按照我的意愿处理连接.根据我的阅读,它似乎相当稳定,而Engine.io目前有一些问题.

我的应用程序在单个域上的Nginx路由器后面运行,因此我不需要SockJS提供的跨域功能.但是,由于提供此功能,SockJS根本不公开客户端的cookie数据.到目前为止,我通过cookie和查询字符串令牌对Socket.io进行了2因素授权,而这对SockJS来说是不可能的(使用Engine.io).

我已经阅读了几乎所有可用的内容和两者的优点和缺点,但似乎到目前为止没有太多讨论或发布,特别是关于Engine.io(这里只有8个问题用engine.io标记).

你喜欢哪2个图书馆中的哪一个？你在生产中使用它们吗？

哪一个可能会更积极地维持,并且在未来可能比另一个更具优势？

brennebeck.. 5

你看过Primus吗？它提供了您提到的cookie要求,它支持所有可用的主要 "实时"/ websocket库,并且是一个非常活跃的项目.对我而言,听起来像供应商锁定可能是你的关注,而Primus会解决这个问题.

它使用插件系统的事实也应该a)使你更容易扩展,如果需要和b)可能实际上有一个已经做你需要的社区插件.

你喜欢哪2个图书馆中的哪一个？你在生产中使用它们吗？

我只通过Vert.x API使用了SockJS,它是一个内部项目,我会考虑"生产",但不是面向消费者应用的生产.也就是说,它表现得非常好.

哪一个可能会更积极地维持,并且在未来可能比另一个更具优势？

只是查看Engine.io和SockJS的提交历史,以及Auttomatic支持Engine.io这一事实使我倾向于认为它会在更长的时间内更稳定,但当然这是值得商榷的.看看Engine.io和SockJS的问题是另一个值得评价的好地方,但由于它们都是分散在多个回购中,所以应该采取一些盐.我不确定Automattic在哪里/如何使用Engine/Socket.io,但如果它在WordPress.com或其中一个插件中,它有大规模的生产大规模战斗测试.

编辑:更改答案以反映Primus作者在下面的评论中确认的cookie支持