Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Refactor push connections #646

Closed
mworrell opened this Issue Sep 5, 2013 · 12 comments

Comments

Projects
None yet
4 participants
Owner

mworrell commented Sep 5, 2013

Currently we are using a home-grown comet/websocket library for the push connections. This was very sensible in 2009 when no other libraries were around.

Currently there are libraries managing push connections. I think that it is good to evaluate which library is best and replace our own solution.

Options:

cc: @kaos @arjan @mmzeeman

Owner

arjan commented Sep 5, 2013

Recent versions of socket.io seem indeed like a feature framework bloat thing, if you read yuri's comments in the readme of the erlang implementation, https://github.com/yrashk/socket.io-erlang

Owner

mworrell commented Sep 5, 2013

That makes http://sockjs.org much more attractive.
There is also an Erlang server: https://github.com/sockjs/sockjs-erlang

Owner

mmzeeman commented Sep 5, 2013

Some issues i've encountered.

  • Comet on port 80 blocked by proxies. (In corporate environments and by mobile providers)
  • WebSocket on port 80 blocked by proxies (In corporate environments and by mobile providers)
  • Empty shell WebSocket object on Samsung's version of Android… WebSocket exists, but it doesn't do anything.
  • WebSocket connection setup problems on recent version of Chrome. After new WebSocket(..) no handshake is sent over the wire.

So it is nice to also have fallbacks methods ready. For channel we start with trying a websocket on port 443. That usually works because traffic on that port is not checked by mobile providers and corporate firewalls.

Owner

mmzeeman commented Sep 5, 2013

Another library we can consider to use is engine.io, which is actually the transport layer of socket.io.

https://github.com/LearnBoost/engine.io

Owner

mmzeeman commented Sep 8, 2013

After having looked at the protocol definitions of sock.js and engine.io I must say I like engine.io better.

  • It is simpler, has less transports and doesn't require one to use json as packet format.
  • Robust connection strategy. It is always started as xhr or jsonp polling. The ws or flashsocket is tested on the
    side, when it works the connection is upgraded to ws of flash.
  • Sock.js is written in coffee script, not plain js.
Owner

arjan commented Sep 8, 2013

Nice summary, 👍 for using engine.io, then!

Owner

mworrell commented Sep 9, 2013

Indeed. I agree with the comments about sock.js - seems more like a framework for node applications than a transport library.

engine.io 👍

Owner

kaos commented Sep 9, 2013

I concur :) 👍

@ghost ghost assigned mworrell Sep 9, 2013

Owner

mworrell commented Sep 9, 2013

I need a more stable session/page-session, so will try to get this in the next release.

Owner

arjan commented Mar 31, 2014

so is this still relevant?

Owner

mmzeeman commented Mar 31, 2014

Marc did a nice refactor of the zotonic stream. Works very nicely in practice.

so is this still relevant?


Reply to this email directly or view it on GitHub.

Owner

mworrell commented Mar 31, 2014

Indeed, works well. No complaints on maxclass and other projects.

This issue can be closed.

Sent from my iPhone

On 31 mrt. 2014, at 22:22, Maas-Maarten Zeeman notifications@github.com wrote:

Marc did a nice refactor of the zotonic stream. Works very nicely in practice.

so is this still relevant?


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

@arjan arjan closed this Apr 1, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment