Hi all,
I wanted to ask your feedback on a proposed change I want to make to the
ASGI spec for channel layers.
In particular, my goal is to make it so that Daphne only has to receive()
on a single channel at any time, massively simplifying the work it takes to
poll for new messages and the overhead that switching channel sets all the
time caused.
The way I want to do this is to redefine process-local channels - those
with a ! in them - so that they are written like this:
http.response.PROCESSID!LOCALID
Then, change the semantics of receive() so that you only call
channel_layer.receive(["http.response.PROCESSID!"])
And this then receives any message sent to any channel with that prefix.
The channel name returned from receive() is still the full name as sent by
the client; it's basically acting as a very limited wildcard.
This will allow Daphne (and any other server) to listen on just a single
process-local channel, with a random part made by the process at boot (e.g.
"http.response.A34GF3!"), and then internally dispatch messages as they
come in to the appropriate client socket. It also means that the client API
- the one seen by end-developers and the Channels library itself - does not
change at all, as the reply_channel can still be set to something like
"http.response.A34GF3!K89C3", and everything will flow correctly.
It's better than full wildcard support as that may be very inefficient to
implement depending on the server; the limitation means that
implementations can just deliver into queues based on the non-local part
and stuff the "full" channel name into the message storage area, and unpack
it again on receive.
The potential benefits to efficiency are hard to understate; the current
definition of process-local channels was meant to allow channel layers to
do something like this internally but it still needed server code to swap
out the list of things it was listening on every receive() call. By
removing this abstraction, servers can be written with a single tight loop
around a fixed set of channel names, and we can block way more efficiently
on servers like Redis.
I want to know if anyone has any feedback on this, especially from the
"potential problems" department; if not, I'm going to try and get this out
before DjangoCon Europe.
Thanks!
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFwN1urL6dj-X6fF%2BDAPhz5jJHmYXTX6GV0M7Y5iGxSOgog8rA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
