On Wednesday, April 17, 2013 8:10:15 AM UTC+2, Aymeric Augustin wrote: > > > Yes, that's why https://github.com/aaugustin/django-c10k-demo/ builds > upon Tulip. > > Unfortunately, that choice makes it unsuitable for inclusion in Django > until we drop support for Python 3.3 and all earlier versions, which isn't > going to happen soon. > > There's another issue: Django is designed to be deployed over WSGI, and > WSGI is incompatible with websockets. A new revision of WSGI would help. > > It's encouraging to hear that WebSockets are at least on some sort of hypothetical roadmap. I've been using gevent-socketio in a Django app in small scale production use, for about one year now. One of the biggest drawbacks of WebSockets has been the very slow response from the likes of Apache and Nginx to offer support for them. For this reason, I deployed my setup using a custom worker class in gunicorn (custom, mainly for the reason of supporting SSL).
WebSockets are difficult, if not impossible, to (reverse) proxy via traditional means. Apache's mod_proxy certainly doesn't work, nor will any other HTTP 1.0 proxy (of which there are still a few), since the lack the ability to handle the protocol upgrade. I've seen a few abortive attempts at writing simple TCP proxy modules, but often these will do the WebSocket protocol upgrade too early, before it gets to your WSGI app - which is a problem for gevent-socketio at least, since it needs to actually see whether the client is offering a WS protocol upgrade, and choose an alternate transport if not. IIRC, the main reason why "strict" WSGI does not support WebSockets is that WSGI expects to specify the response content length, which is obviously not possible for a long running WebSocket connection. uWSGI are doing some interesting stuff with WebSockets, and since version 1.4, they are supported natively by the uWSGI app server. I've read some reports that mod_uwsgi (for Apache) can also handle WebSockets in an Apache environment. I believe it does this by passing the raw HTTP body through to the WSGI app. Since the uWSGI app server can terminate HTTP/S connections directly though, it would be feasible to run this without any Apache / Nginx at all - although I'm not sure whether this is recommended in a production setup. On the pure Django side of things, one of the challenges I encountered was "IDLE IN TRANSACTION" hanging DB connections in the long-running WebSocket views. I really ought to research a more elegant solution to this, but for now I'm just doing all my DB queries early in the view, then fairly brutally closing the DB connection before entering the long-running WS poll loop. I suspect that manual transaction handling would be a better alternative to this, but it does raise an interesting point - namely, that Django has long been designed for a fairly vanilla request/response method of operation, and may need some rethinking if it is to support long-running connections. Is there any possibility that Tulip could be backported to Python 2.7, or are we kinda past caring about 2.x? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
