Alternative Tornado (python framework) socket.io server implementation

[Serge Koval]

Hello,

I implemented alternative python socket.io integration library which
works on top of the Tornado framework.
Unfortunately, looks like original library
(https://github.com/SocketTornadIO/SocketTornad.IO/) was abandoned
and has several serious bugs which were not fixed for last several months.

Library supports all socket.io transports (0.6.x branch), does not
have any dependencies except of the tornado (and simplejson on python <
2.6),
handles server-side on_open/on_close for polling transports, properly
works with unicode, etc.

It can be found here: https://github.com/MrJoes/tornadio

Hope you'll like it.

Thanks,
Serge.

[Nathanael Abbotts]

Looks great! Any chance of a Python client library? That's what I really need.

[Christopher Becker]

Why don't standard unix sockets, http/rest or other protocols work for your needs? Websocket isn't really going to offer any benefits over other established protocols, unless you intend to use it in a browser.

[Christopher Becker]

This is great, was initially really excited about sockettornad.io but it does indeed suffer from some issues. I've abandoned websocket for the time being due to the security flaw that was recently found. Having a socket abstraction for other polling mechanisms is still crazy valuable, so I may dig into your repo soon - long polling is still our primary "streaming" mechanism.

[Alexandros Tzortzidis]

If what you want is asynchronous remote message passing, you can use redis over network exclusively for it's pub/sub feature. Stable libraries are available for both node.js/python in the case it satisfies your needs.

Alex "Chorvus" Tzortzidis

[Sergey Koval]

Hi,

 It depends what you're trying to achieve.

1. If you just want connectivity with socket.io server, pick any client websocket library and use socket.io protocol on top of it (you can get it from tornadio). All you will have to do is to respond to the heartbeats sent from the server to keep connection alive.

2. If you need complete implementation of the socket.io client using python - that's completely different story.

Serge.

On Wed, Feb 2, 2011 at 10:20 PM, Nathanael Abbotts <nat.a...@gmail.com> wrote:

[Sergey Koval]

Alternative solution would be to use ZeroMQ. 

Bindings are available for all (well, almost) languages. Python bindings support Tornado for async operation.

Serge.

[Sergey Koval]

Hi Christopher,

As fair as I know, original websocket implementation had security issue, which then was fixed by more complex handshake. Tornado websocket implementation only works with newer version of the websockets, which have security issue fixed.

Or something completely new was found recently?

Serge.

[Christopher Becker]

Yes, that sounds like the same flaw I'm talking about:

http://cometdaily.com/2010/12/07/websockets-disconnected-for-firefox-4/

http://www.adambarth.com/experimental/websocket.pdf

The problem is that browsers (ff and opera, maybe chrome as well?) almost immediately withdrew support for websocket, to be returned at a later date after the protocol is updated.  As a result the additional proxy/load balancer configuration and extra code associated with websocket were no longer worth keeping in our system.

[Nathanael Abbotts]

It needs to be socket.io, as it has to connect to a server which exclusively uses the socket.io library for client communication. 

[Christopher Becker]

If the server is really meant to support python clients for communications, and there is absolutely no protocol available other than websocket+socket.io for this, then you will have to write a client in python - it doesn't exist yet as far as I know. You wouldn't need to worry about all of the socket.io fall-back (polling) support here - a websocket-only client would do fine.

An other option (expensive, not production-friendly) is to instantiate a webkit browser in your python program and utilize the JS websocket implementation in a "real" browser programmatically. But honestly that would only make sense if you want to throw together a very rough prototype.

Personally I think a python client lib doesn't exist for a good reason - socket.io wasn't meant for this. I would question the need for using socket.io exclusively in all communications with this server, even from non-browser clients.