Using WebSockets in the single cell server

[Juanlu001]

TL;DR: Let's use WebSockets again in the new scalable notebook with
https://bitbucket.org/Jeffrey/gevent-socketio

I have been studying the single cell Python compute service (aka
simply-python-db-compute), trying to run it, reporting a few issues
and thinking about it, and I'd like to point out one thing that makes
me feel uncomfortable: the fact that we are

a) polling the server from the client to request new entries on the
database, and
b) polling the database from the server to request new pieces of code
to be executed.

About the client part: I am aware that this has been discussed before,
when the discussion about the need of a scalable notebook server
began, but I would like to resurrect the WebSockets thing. This idea
appears in the Alex Leone document mentioned in the wiki (http://
bit.ly/jfsfwI), but there were some problems with them mentioned by
William (http://groups.google.com/group/sage-notebook/msg/
43406c5bd1c4d668) Jason (http://groups.google.com/group/sage-notebook/
msg/109b66638a7af4f9) and others in those threads.

*But*, I have been experimenting lately with gevent-socketio (https://
bitbucket.org/Jeffrey/gevent-socketio), an extension to the gevent
library (http://www.gevent.org) which subclasses gevent's WSGI server
to provide a full Socket.IO API. For those who don't know, Socket.IO
is a JavaScript library that allows to use WebSockets while gracefully
degrading to other methods (called "transports") such as Flash, long-
polling, etc. when WebSockets are not available, so the problem of
browser compatibility gets addressed (http://socket.io/#browser-
support).
FYI, I managed to write a fully WSGI compliant, asynchronous chat
using Socket.IO based on Flask in 100 lines of code. Take into account
that it was my very first Flask app and my very first gevent app. I
could event write a very, very sloppy (and probably unfinished)
compute server based on this chat and ØMQ. If there is interest, I can
release the code.

Now, and I'm finishing (thanks God), would it be possible to avoid
polling from the client by using the method I exposed before?

And, about the database part: wouldn't it be easier to notify the
device with a ØMQ socket when there is a new message in the database?

[Jason Grout]

> compute server based on this chat and �MQ. If there is interest, I can
> release the code.

Great! I'm glad you're looking at this. It sounds like it might be the
right time to look at this again seriously.

There are a couple of main reasons why we have not heavily pursued
websockets in our project at Drake up to this point. I should mention
that Ira Hanson (here at Drake) did a little exploration with websockets
at the beginning of the summer.

1. The libraries were not mature when we started, and we'd rather spend
time writing the code that was unique to our project, especially since
we were still experimenting with different designs. We tried to design
with an eye towards supporting websockets or long polling eventually,
though. Along with the libraries, the technology itself wasn't mature,
which I think was pointed out in previous threads (sorry, I don't have
internet right now, so I can't look up the previous threads)

From what work you've said, it sounds like the libraries are getting to
the point that we can look at it seriously. I would love to support
socket.io, which (IIRC) supports a variety of polling strategies seamlessly.

2. I anticipate a large number of requests relative to the device
backends, so a computation might sit for a while (a second or two) in
the database before being picked up and evaluated. A batch-processing
system seems more efficient for that case. However, having a websocket
connection for interacts seems to make a lot of sense. Interacts will
probably be a significant portion of the traffic.

3. We needed a system that would work across a wide variety of browsers
and versions, so we implemented the lowest common denominator (simple
polling). I believe socket.io takes care of the cross-browser issues,
so again, it sounds like it might be great to implement this.

4. We also designed with an eye toward having a very simple web service.
Clients that use the web service may or may not be able to support
websockets, so again, we implemented the lowest common denominator
simple client polling.

>
> Now, and I'm finishing (thanks God), would it be possible to avoid
> polling from the client by using the method I exposed before?

I would love to see the client polling removed for the clients that can
support it.

>
> And, about the database part: wouldn't it be easier to notify the

> device with a �MQ socket when there is a new message in the database?
>

The goal here was minimizing traffic by batching requests, with an eye
towards sustaining a large number of requests with a low average
response time. I think this area is ripe for experimenting to see if
notifying the devices like you suggest can sustain the same load.

Thanks,

Jason

[Juanlu001]

I am glad you liked the idea. I am not an experienced programmer, and
though I have been reading the code and trying to grasp its logic it
is still difficult to me, but I am eager to collaborate and if I get
ready before the end of the summer I could try to make a fork and
implement the Socket.IO part. If that is too much for me... at least I
could improve the README :P

[Jason Grout]

On 6/28/11 2:20 PM, Juanlu001 wrote:
> I am glad you liked the idea. I am not an experienced programmer, and
> though I have been reading the code and trying to grasp its logic it
> is still difficult to me, but I am eager to collaborate and if I get
> ready before the end of the summer I could try to make a fork and
> implement the Socket.IO part. If that is too much for me... at least I
> could improve the README :P
>

Ira just spent a lot of time in the last couple of days documenting
things. I just pushed his changes to the master branch, so hopefully
the documentation is better now. He's working on the README right now too.

Ira: could you add to the readme or somewhere a short description of the
overall architecture? I know there's something in the device_process
file that documents part of the architecture, but it would be very
valuable to have a big overview of how things work.

Thanks,

Jason

[Juanlu001]

Your student is doing a great work on this. It is awesome that the
project goes forward so fast!

[Jason Grout]

On 6/29/11 2:29 AM, Juanlu001 wrote:
> Your student is doing a great work on this. It is awesome that the
> project goes forward so fast!

We have Drake University and the NSF to thank for funding me, Ira, and
another student (Alex Kramer) to work on this!

That said, work is winding down on this over the next two weeks, so it
would be *great* to get feedback and suggestions on this ASAP. We hope
to have something that is polished in about two weeks.

Thanks,

Jason

[Juanlu001]

On Wednesday, June 29, 2011 3:10:07 PM UTC+2, Jason Grout wrote:

That said, work is winding down on this over the next two weeks, so it
would be *great* to get feedback and suggestions on this ASAP.  We hope
to have something that is polished in about two weeks.

Are you going to set up some kind of public testing server by then?  

[Jason Grout]

There already is: sagemath.org:5467.

However, it's running code from maybe a week ago.

Jason