0

I made a little app to act as a browser using requests, that makes use of library's capabilities to handle sessions and pass the CSRF tokens to Django properly.

There are mulitple apps of this connecting to the server, where authentication and sessions need to be handled, and this is done.

I need to have the client permanently connected to the Django server side, and I think this could be handled by setting the session only expires when the client closes or disconnects.

The other thing I want to do is to make django start sending data based on some events on the server making use of the open sessions with the authenticated and logged in clients, how can I do this?

Keeping in mind that the function that will take care of the events on the server and correspondingly sending some message/data to the client is not the view function, where return HttpResponse can be utilized; even though, HttpResponse can only send the response once per request not per some event that might be repeated, hence multiple responses could be sent.

securecurve
  • 5,589
  • 5
  • 45
  • 80

1 Answers1

1

It would require a huge amount of effort to get django to do this without impossible memory requirements, and even then, it would still be harder than it's worth, so i'll present some alternatives instead.

You might see if django-socketio would help you do what you want, however it seems like it's pretty far out of date.

Last time I had to push real-time events from a django app to the client, I used a rabbitmq server to deliver packets of messages to queues that connected to a very thin server I built using tornado, with a basic long-polling approach. That worked, but it ended up being a complicated system, with a lot of moving parts that isn't the most maintainable.

More recently when I've had to do things with events being pushed to the client, I used node.js + socket.io, which is a lot simpler to get working (at least if your not using the full routing power of rabbit, which I was not.

If you want to use that setup alongside django, you run a seperate node.js server alongside however you're serving django, and put HAproxy in front of the whole stack, to avoid cross domain issues. The only issue remaining would be how to connect between the node server and your django app, which could be HTTP calls on a private port, a redis pub/sub setup, some sort of messaging setup like rabbit or zeromq, or anything else you dream up.

JeffS
  • 2,647
  • 2
  • 19
  • 24
  • Thanks JeffS. After reading your answer, I can conclude that using the simplest way of doing such implementation with django without using Node.js (which will add unneeded complexity to my project) is to use rabbitmq or similar, while using some messaging library at the client side, like pymq for example. What I really don't understand in your answer is, why you use Tornado in the client side, is that because you faced problems handling messages using client message queuing only, or you mean something different I don't get it here? – securecurve Dec 18 '12 at 06:24
  • 1
    In our situation, we required that the client be a web browser which can't connect directly to rabbit, so what we did is write a small (<100 lines of python) server in Tornado + Stormed that would basically translate between HTTP Long Polling and rabbit. – JeffS Dec 18 '12 at 13:46
  • I see your point, things are clearer to me now. I'll do some research and pass my questions, if any, to this SO thread. Thanks again :)) – securecurve Dec 18 '12 at 15:04
  • I decided to use Tornado and Django behind Nginx, that will do the routing and static file serving, and rabbitmq at the back of all of them in server side. In client side, I'll use Tornado Async Http clinet plus Stormed for as an MQ client. Could you please pass me a sample code for tornado in client side that communicates with a long-pulling tornado server and how you ingegrated Storemd with? The other thing is, to pass files back in forth between client and sserver, is the design I described above will work Will this client https://gist.github.com/4370439 work with long comet servers? – securecurve Dec 24 '12 at 19:29
  • 1
    Any http client should be able to do long polling, so long as you can set the timeout. I'm actually not sure how that gist works, since I don't know where the httpclient comes from. This question shows how to do it with the standard http client http://stackoverflow.com/questions/265720/http-request-timeout – JeffS Dec 25 '12 at 02:08
  • The client probably doesn't need to be asyncronous at all, since the client will probably only have one connection, just putting it in a seperate thread should work well. If you go with the design I was talking about it, you shouldn't need to have a rabbit client in your client at all – JeffS Dec 25 '12 at 02:11
  • I really appreciate your help. Just for the sake of completeness, when would I need a rabbit client at the client side. This will help me to better understand the picture. – securecurve Dec 25 '12 at 06:29
  • The tornado server is basically there to provide a specific API to connect to poll certain queues on the rabbit server. If you wanted to remove the tornado server from the picture, requiring that every client is also an amqp client, and that authentication is correctly handled by rabbit, then you'd want to have a rabbit client in your client. – JeffS Dec 25 '12 at 17:02