3 ms·

Well, you always need the client to reach out first, since it is not otherwise addressable. ;) But this doesn't mean it has to poll. With a separate gateway tha

Well, you always need the client to reach out first, since it is not otherwise addressable. ;) But this doesn't mean it has to poll. With a separate gateway that supports Websockets or Server Sent Events, it should be enough for the client to make an initial request to bootstrap the connection, and then the server can send as many messages as it wants downstream.

falcolas 13y ago
> it should be enough for the client to make an initial request to bootstrap the connection, and then the server can send as many messages as it wants downstream. Yes, that's the point of websockets; but what was discussed here is a program acting as a bridge between django and websockets using http to speak to django. http does not support such asynchronous communication. You get one response for one request. How can a backend send a new response if there is no open request from the intermediary? Sure, you can hack http by refusing to close the stream of a response and sending data intermittently (well, if you're using a django->apache/nginx protocol that supports streaming responses), but then you're no longer speaking http; you're speaking your own protocol over http. Sure, you can have your intermediary poll django, which reduces some of the overhead since you're bypassing the external network stack, but you're still relying on only sending messages every $poll_interval. Sure, you can create some secondary process through manage.py that runs and communicates with the intermediary directly, but then you're no longer speaking http to Django. If you want async communication between your client and your server using websockets, you can't rely on speaking http to anybody; it just isn't compatible with truly asynchronous websocket communication.
- rbanffy 13y ago
  The HTTP site of the middleware server should be able to make and receive HTTP requests. If something causes an event in Django, it can make a request to the HTTP server side of the middleware and send a message to all listening websocket clients.
  - falcolas 13y ago
    Aaah, I think my confusion was from your misuse of the term middleware. When used in the context of Django, middleware is a layer in a stack of WSGI calls, not a standalone daemon which accepts and receives http posts and websockets. I could see such a standalone daemon working, but it would seem like more straightforward to just write a daemon which handles websockets and your application logic on its own.

falcolas 13y ago

> it should be enough for the client to make an initial request to bootstrap the connection, and then the server can send as many messages as it wants downstream. Yes, that's the point of websockets; but what was discussed here is a program acting as a bridge between django and websockets using http to speak to django. http does not support such asynchronous communication. You get one response for one request. How can a backend send a new response if there is no open request from the intermediary? Sure, you can hack http by refusing to close the stream of a response and sending data intermittently (well, if you're using a django->apache/nginx protocol that supports streaming responses), but then you're no longer speaking http; you're speaking your own protocol over http. Sure, you can have your intermediary poll django, which reduces some of the overhead since you're bypassing the external network stack, but you're still relying on only sending messages every $poll_interval. Sure, you can create some secondary process through manage.py that runs and communicates with the intermediary directly, but then you're no longer speaking http to Django. If you want async communication between your client and your server using websockets, you can't rely on speaking http to anybody; it just isn't compatible with truly asynchronous websocket communication.

rbanffy 13y ago
The HTTP site of the middleware server should be able to make and receive HTTP requests. If something causes an event in Django, it can make a request to the HTTP server side of the middleware and send a message to all listening websocket clients.
- falcolas 13y ago
  Aaah, I think my confusion was from your misuse of the term middleware. When used in the context of Django, middleware is a layer in a stack of WSGI calls, not a standalone daemon which accepts and receives http posts and websockets. I could see such a standalone daemon working, but it would seem like more straightforward to just write a daemon which handles websockets and your application logic on its own.