Recently I released ws4py, a package that provides client and server WebSocket support for Python 2.6 and 2.7.
Let’s first have a quick overview of what ws4py offers for now:
- WebSocket specification draft-10 of the current specification.
- A threaded client. This gives a simple client that doesn’t require an external dependency.
- A Tornado client. This client is based on Tornado 2.0 which is quite a popular way of running asynchronous networking code these days. Tornado provides its own server implementation so I didn’t include mine in ws4py.
- A CherryPy extension so that you can integrate WebSocket from within your CherryPy 3.2.1 server.
- A gevent server based on the popular gevent library. This is courtesy of Jeff Lindsay.
- Based on Jeff’s work, a pure WSGI middleware as well (available in the current master branch only until the next release).
- ws4py runs on Android devices thanks to the SL4A package
Hopefully more client and servers will be added along the way as well as Python 3.x support. The former should be rather simple to add due to the way I designed ws4py.
The main idea is to make a distinction between the bytes provider and the bytes processing. The former is essentially reading and writing bytes from the connected socket. The latter is the function of making something out of the received bytes based on the WebSocket specification. In most implementations I have seen so far, both are rather heavily intertwined making it difficult to use a different bytes provider.
ws4py tries a different path by relying on a great feature of Python: the possibility to send data back to a generator. For instance, the frame parsing yields the quantity of bytes each time it needs more and the caller feeds back the generator those bytes once they are received. In fact, the caller of a frame parser is a stream object which acts the same way. The caller of that stream object is in fact the bytes provider (a client or a server). The stream is in charge of aggregating frames into a WebSocket message. Thanks to that design, both the frame and stream objects are totally unaware of the bytes provider and can be easily adapted in various contexts (gevent, tornado, CherryPy, etc.).
On my TODO list for ws4py:
- Upgrade to a more recent version of the specification
- Python 3.x implementation
- Better documentation, read, write documentation.
- Better performances on very large WebSocket messages