On Tue, Mar 28, 2017 at 10:39 AM, Oskar Hahn <m...@oshahn.de> wrote:
> Hi,
>
> I am not sure, if I understand your proposal correctly. Do you mean, the
> asgi server has to listen only to one channel or do you mean it has to
> listen to one channel of any channel-type?
>
> So with redis, do I have to call
>
> "BLPOP LOCALID TIMEOUT"
>
> or do I have to call
>
> "BLPOP http.response.PROCESSID! TIMEOUT" and
> "BLPOP websocket.send.PROCESSID! TIMEOUT"
>
> I think you mean the second one, but then your goal, that daphne has
> only to listen "on a single channel at any time" seams not be fulfilled.
>
> I would like a solution, were the asgi server really listens only to one
> channel. I don't like the idea, that there is a fixed set of channel
> names. This seems not flexible.
>
I mean that the server now has the option to go down to one or two
channels. BLPOP supports multiple channel names, so the two-channel case
can be done as:
BLPOP http.response.PROCESSID! websocket.send.PROCESSID! TIMEOUT
However, as this would play oddly with sharding, I have instead modified
Daphne to use a single `daphne.response.PROCESSID!` channel for both HTTP
and WebSocket replies - the name of the reply_channel is entirely up to the
server, after all.
>
>
> Another thing:
>
> Currently the usual case looks like this:
>
> Time | ASGI Application | ASGI Server |
> ----------------------------------------------
> 1 | | receive("foo!123") |
> 2 | send("foo!123") | |
>
> First, the asgi server listens to a specific channel, for example
> http.response.RANDOMPART!CLIENTID. Then the Django app sends something
> to this channel and the asgi server gets it.
>
> But what should happen when the django app sends to a channel and the
> asgi server starts to listen on this channel at a later time:
>
> Time | ASGI Application | ASGI Server |
> ----------------------------------------------
> 1 | send("foo!123") | |
> 2 | | receive("foo!123") |
>
> With the current implementation the messages remains in the asgi-backend
> until it expires. So the ASGI Server can fetch it later.
>
> With your proposal this could change. The ASGI-Server will get the
> message from the asgi-backend, as soon, as it was send by the
> application. So if nobody has called receive() for this channel, it
> either has to be dropped or saved.
>
> Do you have a recommendation what to do with a message, that can not be
> dispatched to a client socket? This should not happen so often.
>
Well, given that the reply channel name is generated by the server itself,
it should not be possible that the server does not know about it when the
client sends it, as the client had to get it from somewhere. If a message
is received for a non-existent reply channel, which is possible if, say,
the socket closed before the response could be read, the server will log
this and continue on.
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAFwN1upats9T9O0aL%3Dt7WF_%2Beg5CmLtEBUD9cSEr9Rn%3Dibgjow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
