Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Refactor push connections #646

Closed
mworrell opened this Issue · 12 comments

4 participants

@mworrell
Owner

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

@arjan
Owner

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

@mworrell
Owner

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

@mmzeeman
Owner

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.

@mmzeeman
Owner

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

@mmzeeman
Owner

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.
@arjan
Owner

Nice summary, :+1: for using engine.io, then!

@mworrell
Owner

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

engine.io :+1:

@kaos
Owner

I concur :) :+1:

@mworrell mworrell was assigned
@mworrell
Owner

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

@arjan
Owner

so is this still relevant?

@mmzeeman
Owner
@mworrell
Owner
@arjan arjan closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.