Out of Date Protocol #11

Closed
paddyforan opened this Issue Oct 6, 2011 · 4 comments

Projects

None yet

2 participants

@paddyforan

Socket.IO is on 0.8.4 now; the protocol has been upgraded quite a bit. Are there any plans to upgrade this library to match? Is there anything you could use help on in bringing the project up to date? I'd love to see if I could get this working on App Engine as an alternative to the Channel API. Google's App Engine team is really interested to see what happens if it can work, too.

@paddyforan

Stupid question, sorry. Found your testing tree. How stable is that? I really am just looking for a proof of concept at the moment, to see if running this under App Engine (Flash and Websockets are out, but JSONP and XHR are possible) is possible-- e.g., if this is not tied to a library that is restricted or stubbed in the sandbox environment.

@madari
Owner
madari commented Oct 6, 2011

Hi,

Work has already started on the testing branch. Currently it provides enough features to
able to run the Socket.IO chat example that is bundled with the official node-server (bleeding edge).

However, the rewritten connection-model is flawed and is not full-duplex. It requires more work. The connections
can deadlock in certain scenarios. Other important things missing are:

  • documentation (+ cosmetics)
  • CORS support
  • API validation (is the websocket-style API any good in the context of Socket.IO or should we stick
    with the current callback-style API? I personally prefer the new Go-style API big time)

The App Engine support is something that would be really really cool to have. Unfortunately, I have no previous experience with the App Engine. I skimmed through the limitations (http://code.google.com/appengine/docs/whatisgoogleappengine.html#The_Application_Environment) and the first thing
that popped was this:

Application code only runs in response to a web request, a queued task, or a scheduled task, and must return response data within 30 seconds in any case. A request handler cannot spawn a sub-process or execute code after the response has been sent.

That immediately rules out all the streaming transports and leaves us only with jsonp-polling and xhr-polling. It also
means that the state of the server (incl. connections) would have to be persisted within the datastore.
I think we should raise another issue for the App Engine matter and think about it more.

@madari
Owner
madari commented Oct 6, 2011

I somehow managed to miss your own reply to this thread but yeah, my response above should be able answer your follow-up questions too.

JP

@paddyforan

Thanks for the speedy response!

App Engine definitely won't allow Websockets or Flash sockets. Essentially, if it's not a hack of the HTTP protocol, it's almost certainly not going to work.

On the plus side, JSONP polling and XHR polling have been demonstrated to work to great effect on App Engine. I do think you're right, though, that the handshake-driven nature of Socket.IO is going to make it prohibitively difficult to apply to the horizontally-scaled App Engine architecture. The most performant way I can think of to do it is to memcache the state and retrieve it, but that's still far from ideal. Also, if that memcache state gets lost, the open connections are pretty much screwed.

Thanks for getting back to me. Sorry, I clearly didn't think through this enough.

@paddyforan paddyforan closed this Oct 6, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment