mirror of
https://github.com/django/daphne.git
synced 2025-04-21 17:22:03 +03:00
commit
976faeca9a
|
@ -28,7 +28,7 @@ The core of Channels is, unsurprisingly, a datastructure called a *channel*.
|
|||
What is a channel? It is an *ordered*, *first-in first-out queue* with
|
||||
*message expiry* and *at-most-once delivery* to *only one listener at a time*.
|
||||
|
||||
You can think of it as analagous to a task queue - messages are put onto
|
||||
You can think of it as analogous to a task queue - messages are put onto
|
||||
the channel by *producers*, and then given to just one of the *consumers*
|
||||
listening to that channnel.
|
||||
|
||||
|
|
|
@ -244,7 +244,7 @@ connection, as part of the query string (e.g. ``wss://host/websocket?room=abc``)
|
|||
|
||||
The ``reply_channel`` attribute you've seen before is our unique pointer to the
|
||||
open WebSocket - because it varies between different clients, it's how we can
|
||||
keep track of "who" a message is from. Remember, Channels is network-trasparent
|
||||
keep track of "who" a message is from. Remember, Channels is network-transparent
|
||||
and can run on multiple workers, so you can't just store things locally in
|
||||
global variables or similar.
|
||||
|
||||
|
@ -384,7 +384,7 @@ Django session ID as part of the URL, like this::
|
|||
|
||||
You can get the current session key in a template with ``{{ request.session.session_key }}``.
|
||||
Note that Channels can't work with signed cookie sessions - since only HTTP
|
||||
responses can set cookies, it needs a backend it can write to to separately to
|
||||
responses can set cookies, it needs a backend it can write to to separately
|
||||
store state.
|
||||
|
||||
|
||||
|
@ -484,7 +484,7 @@ whereas you'd naturally expect ``receive`` to run after ``connect``.
|
|||
But, of course, Channels has a solution - the ``linearize`` decorator. Any
|
||||
handler decorated with this will use locking to ensure it does not run at the
|
||||
same time as any other view with ``linearize`` **on messages with the same reply channel**.
|
||||
That means your site will happily mutitask with lots of different people's messages,
|
||||
That means your site will happily multitask with lots of different people's messages,
|
||||
but if two happen to try to run at the same time for the same client, they'll
|
||||
be deconflicted.
|
||||
|
||||
|
|
|
@ -21,8 +21,8 @@ That's it! Once enabled, ``channels`` will integrate itself into Django and
|
|||
take control of the ``runserver`` command. See :doc:`getting-started` for more.
|
||||
|
||||
|
||||
Installing the lastest development version
|
||||
------------------------------------------
|
||||
Installing the latest development version
|
||||
-----------------------------------------
|
||||
|
||||
To install the latest version of Channels, clone the repo, change to the repo,
|
||||
change to the repo directory, and pip install it into your current virtual
|
||||
|
|
|
@ -15,7 +15,7 @@ the received data (or something else based on ``reply_channel``).
|
|||
|
||||
All messages must be able to be encoded as JSON; channel backends don't
|
||||
necessarily have to use JSON, but we consider it the lowest common denominator
|
||||
for serialisation format compatability.
|
||||
for serialisation format compatibility.
|
||||
|
||||
The size limit on messages is 1MB (while channel backends may support larger
|
||||
sizes, all message formats should stay under this limit, which might include
|
||||
|
|
|
@ -13,7 +13,7 @@ more efficient and user friendly:
|
|||
added to allow moving the user details from the HTTP session to the channel session in the ``connect`` consumer.
|
||||
|
||||
* A ``@linearize`` decorator was added to help ensure a ``connect``/``receive`` pair are not executed
|
||||
simultanously on two different workers.
|
||||
simultaneously on two different workers.
|
||||
|
||||
* Channel backends gained locking mechanisms to support the ``linearize`` feature.
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
Scaling
|
||||
=======
|
||||
|
||||
Of course, one of the downsides of introducing a channel layer to Django it
|
||||
Of course, one of the downsides of introducing a channel layer to Django is
|
||||
that it's something else that must scale. Scaling traditional Django as a
|
||||
WSGI application is easy - you just add more servers and a loadbalancer. Your
|
||||
database is likely to be the thing that stopped scaling before, and there's
|
||||
|
|
Loading…
Reference in New Issue
Block a user