Right - as long as you make clients deal with reconnection (which obviously they should), then as long as your load-balancing has a way to shed connections from a sticky server by closing them then all should be fine.
Honestly, I have always been annoyed at the no-local-context thing in channels; it makes writing code a lot easier, and while the current design may technically be more scalable I'm not sure that holds true given that sockets already have to be sticky thanks to TCP, and my own personal views on "scaling down". My ideal solution is one that allows both approaches, and I'd like to investigate that further. I think you're getting closer to the sort of thing I'm imagining with the uvcorn designs, but I feel like there's still something a little extra that could be done so it's possible to offload over a network easily (as you mention, letting consumers go to channel layers). This is one of the original reasons the message specification is separate from the channel layer stuff; I always knew that my particular arrangement of send-and-receive-in-processes wouldn't work for everyone and everything, so I wanted a common message format we could definitely all agree on too. If we end up with one format for channel names and messages that is spread across two consumption forms (in-process async and cross-process channel layers), I think that would still be a useful enough standard and make a lot more people happy. As for making send() async - I resisted this so far on the grounds that it is "non-blocking", but it involves a network call, so it's not actually non-blocking, obviously. It also technically returns a result, in that you have to be prepared to catch the ChannelFull exception, so it's not like you can have a synchronous API that then ends up being fire-and-forget on an async backend. I wish there was a nicer way to achieve this than having send_async() and send_group_async() methods (etc.), but the only other alternative I see is having the methods all mirrored on an .async object, as in "channel_layer.async.send()". I'm not sure how I feel about that - thoughts? Andrew On Fri, Jun 16, 2017 at 5:49 PM, Tom Christie <[email protected]> wrote: > > I wonder if there is a way of doing something like this well, so that > it's easy to write but also lets you scale later. > > It's not obvious that sticky websockets are *necessarily* problematic for > typically use cases. Couple of things you'd want: > > * Have clients be responsible for graceful reconnects. (This seems like a > reasonable policy in any case.) > * Have instances enforce a maximum number of concurrent websocket requests > that they'll accept. (Optionally combined with load-balancing websocket and > HTTP to different sets of instances.) > > A totally different tack would be a websocket load-balancer proxy that > transparently handles reconnects across the pool of servers, as required. > It doesn't look like Nginx supports that, but it might not be a ridiculous > proposal given that it does support acting as a websocket proxy to multiple > servers. > > However what I'd *like* to do would be to write a consumer that routes > messages to a channel layer. At that point uvicorn would be a fully fledged > alternative implementation to daphne. > > One question there: The channel layer `.send(...)` method is currently a > regular method. Should there be twisted/asyncio equivalents in the spec? > Given that I'm writing an asyncio server I'd ideally like to be able to use > `await channel_layer.send(...)`. (Granted it's only eg. a quick redis hop, > and I do also have the option of running those operations within a separate > thread.) > > -- > 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/3fe6c9c3-8cd2-4e22-bb0e- > 82f28355f866%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/3fe6c9c3-8cd2-4e22-bb0e-82f28355f866%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFwN1urskpBGHOGUoN745xXWS%2Bfb%3DHEv5O_Qwq5WO9DYGYXhjA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
