Using comet sockets

105 views
Skip to first unread message

guruyaya

unread,
Feb 13, 2011, 4:30:29 PM2/13/11
to web2py-users
Every since the demo of EMTE, I'm fascinated by the option of using
comet sockets to do real time processing. Yet I cannot find any
domestication on the usage of comet sockets in web2py.
Can you help direct me to anything that has to do with this issue?
Thanks in advance
Yair

Massimo Di Pierro

unread,
Feb 13, 2011, 4:41:18 PM2/13/11
to web2py-users
Right now the only examples are in web2py/gluon/contrib/
comet_messaging.py

This must be mode more powerful and it is on my todo list. It uses
tornado. It talks to web2py. It is not web2py specific.

Massimo

AsmanCom

unread,
Feb 13, 2011, 7:31:56 PM2/13/11
to web2py-users
Why have you chosen Tornado for this "comet sockets" experiment? it´s
Unix only, right?

I'm currently working on a quite similar comet sockets with web2py
Project,
but I attempt to implement this with hookbox.org which could also be
worth a look.


On 13 Feb., 22:41, Massimo Di Pierro <massimo.dipie...@gmail.com>
wrote:

Massimo Di Pierro

unread,
Feb 13, 2011, 9:13:39 PM2/13/11
to web2py-users
I will take a look. There is a fork for tornado that should work on
windows:

http://groups.google.com/group/python-tornado/browse_thread/thread/675779463dec569e/fa623daa06e41fc5

Anthony

unread,
Feb 13, 2011, 10:59:15 PM2/13/11
to web...@googlegroups.com
On Sunday, February 13, 2011 4:41:18 PM UTC-5, Massimo Di Pierro wrote:
Right now the only examples are in web2py/gluon/contrib/
comet_messaging.py
 
Is "Comet" the right terminology for this? It looks like it uses the new WebSockets protocol, not traditional Comet. My understanding is that Comet refers only to the older HTTP-based long-polling and streaming techniques: http://en.wikipedia.org/wiki/Comet_(programming)
 
Also, if I'm not mistaken, this implements WebSocket communications only in the server-to-client direction, but not from client to server. Do you plan to add capabilities for bi-directional WS communication?
 
Anyway, this is very cool, and I think a nice additional piece of functionality for web2py. Would be neat if we could put together some kind of chat plugin.
 
Anthony

Massimo Di Pierro

unread,
Feb 14, 2011, 9:20:29 AM2/14/11
to web2py-users
websockets use http-based long polling so I think the terminology is
correct, but I may be wrong.

On Feb 13, 9:59 pm, Anthony <abasta...@gmail.com> wrote:
> On Sunday, February 13, 2011 4:41:18 PM UTC-5, Massimo Di Pierro wrote:
>
> > Right now the only examples are in web2py/gluon/contrib/
> > comet_messaging.py
>
> Is "Comet" the right terminology for this? It looks like it uses the new
> WebSockets protocol, not traditional Comet. My understanding is that Comet
> refers only to the older HTTP-based long-polling and streaming techniques:http://en.wikipedia.org/wiki/Comet_(programming)
>
> Also, if I'm not mistaken, this implements WebSocket communications only in
> the server-to-client direction, but not from client to server. Do you plan
> to add capabilities for bi-directional WS communication?

True. The idea is that communication from client should go through
web2py because needs authentication.

Anthony

unread,
Feb 14, 2011, 5:08:04 PM2/14/11
to web...@googlegroups.com
On Monday, February 14, 2011 9:20:29 AM UTC-5, Massimo Di Pierro wrote:
websockets use http-based long polling so I think the terminology is
correct, but I may be wrong.
 
I'm certainly no expert, but from what I've read, it looks like websocket is a separate protocol from HTTP (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-05#section-1.7). I think the initial handshake is over HTTP but then upgraded to a websocket protocol connection (hence the change to the WS/WSS url scheme). Discussions I've seen seem to make a distinction between Comet and WebSockets (e.g., http://websocket.org/quantum.html, http://www.infoq.com/news/2008/12/websockets-vs-comet-ajax).
 
 
Because not all browsers and servers currently support WebSockets, there are some libraries that implement both WebSockets and Comet techniques, transparently falling back to Comet if WS is not available. One example is Socket.IO (http://socket.io/, https://github.com/learnboost/socket.io). By default, Socket.IO uses node.js on the server side (https://github.com/learnboost/socket.io-node). However, there is also a server-side implementation on top of Tornado called TornadIO: https://github.com/MrJoes/tornadio.
 
> Also, if I'm not mistaken, this implements WebSocket communications only in
> the server-to-client direction, but not from client to server. Do you plan
> to add capabilities for bi-directional WS communication?

True. The idea is that communication from client should go through
web2py because needs authentication.
 
I don't know how difficult it would be to implement in web2py, but it sounds like you can authenticate a websocket upon initial connection by sending the session cookie: http://stackoverflow.com/questions/2701373/websockets-authentication/3971418#3971418
 
Best,
Anthony
 
 

Massimo Di Pierro

unread,
Feb 14, 2011, 6:54:28 PM2/14/11
to web2py-users
The problem that the web server needs to keep many connections open
(whether long polling or websocket) and a normal web server cannot
handle the traffic because of too many threads. It requires an async
server like tornado and/or lightweight threads like erlang or node.js.

Implementing it in web2py would be pointless. Yet web2py can work as
middlewere and work with tornado as in the example.

Massimo

On Feb 14, 4:08 pm, Anthony <abasta...@gmail.com> wrote:
> On Monday, February 14, 2011 9:20:29 AM UTC-5, Massimo Di Pierro wrote:
>
> > websockets use http-based long polling so I think the terminology is
> > correct, but I may be wrong.
>
> I'm certainly no expert, but from what I've read, it looks like websocket is
> a separate protocol from HTTP (http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-05#se...).
> I think the initial handshake is over HTTP but then upgraded to a websocket
> protocol connection (hence the change to the WS/WSS url scheme). Discussions
> I've seen seem to make a distinction between Comet and WebSockets (e.g.,http://websocket.org/quantum.html,http://www.infoq.com/news/2008/12/websockets-vs-comet-ajax).
>
> Here's a useful WebSockets rundown from Stackoverflow:http://stackoverflow.com/questions/4262543/what-are-good-resources-fo...
>
> Because not all browsers and servers currently support WebSockets, there are
> some libraries that implement both WebSockets and Comet techniques,
> transparently falling back to Comet if WS is not available. One example is
> Socket.IO (http://socket.io/,https://github.com/learnboost/socket.io). By
> default, Socket.IO uses node.js on the server side (https://github.com/learnboost/socket.io-node). However, there is also a
> server-side implementation on top of Tornado called TornadIO:https://github.com/MrJoes/tornadio.
>
> > > Also, if I'm not mistaken, this implements WebSocket communications only
> > in
> > > the server-to-client direction, but not from client to server. Do you
> > plan
> > > to add capabilities for bi-directional WS communication?
>
> > True. The idea is that communication from client should go through
> > web2py because needs authentication.
>
> I don't know how difficult it would be to implement in web2py, but it sounds
> like you can authenticate a websocket upon initial connection by sending the
> session cookie:http://stackoverflow.com/questions/2701373/websockets-authentication/...
>
> Best,
> Anthony

Anthony

unread,
Feb 14, 2011, 7:15:15 PM2/14/11
to web...@googlegroups.com
On Monday, February 14, 2011 6:54:28 PM UTC-5, Massimo Di Pierro wrote:
The problem that the web server needs to keep many connections open
(whether long polling or websocket) and a normal web server cannot
handle the traffic because of too many threads. It requires an async
server like tornado and/or lightweight threads like erlang or node.js.

Implementing it in web2py would be pointless. Yet web2py can work as
middlewere and work with tornado as in the example.
 
Got it. I assume Tornado would handle all the back-and-forth messaging without involving web2py, but assuming you only need to authenticate once when the socket is first opened (i.e., not every time a message is sent through the socket), might it be feasible to involve web2py in the initial authentication? Or otherwise, could Tornado handle the authentication directly (i.e., confirm the user is logged in before establishing the socket connection) -- would it have to access the web2py session file to do that?
 
Thanks.
 
Anthony
 
Reply all
Reply to author
Forward
0 new messages