Skip to content

Commit

Permalink
Fix channel layer spec.
Browse files Browse the repository at this point in the history
  • Loading branch information
andrewgodwin committed Apr 2, 2018
1 parent 4d48d80 commit 6579c0f
Showing 1 changed file with 6 additions and 30 deletions.
36 changes: 6 additions & 30 deletions docs/channel_layer_spec.rst
Original file line number Diff line number Diff line change
Expand Up @@ -50,8 +50,7 @@ a message more than once or to more than one reader, and must drop messages if
this is necessary to achieve this restriction.

In order to aid with scaling and network architecture, a distinction
is made between channels that have multiple readers, *single-reader channels*
that are read from a single unknown location, and
is made between channels that have multiple readers and
*process-specific channels* that are read from a single known process.

*Normal channel* names contain no type characters, and can be routed however
Expand All @@ -61,15 +60,6 @@ so that a querying client only sees some portion of the messages. Calling
``receive`` on these channels does not guarantee that you will get the
messages in order or that you will get anything if the channel is non-empty.

*Single-reader channel* names contain a question mark
(``?``) character in order to indicate to the channel layer that it must make
these channels appear globally consistent. The ``?`` is always preceded by
the main channel name and followed by a random portion
(e.g. ``mything.foo?S4Hr2d``).Channel layers may use the random portion to help
pin the channel to a server, but reads from this channel by a single process must
always be in-order and return messages if the channel is non-empty. These names
must be generated by the ``new_channel`` call.

*Process-specific channel* names contain an exclamation mark (``!``) that
separates a remote and local part. These channels are received differently;
only the name up to and including the ``!`` character is passed to the
Expand Down Expand Up @@ -174,25 +164,11 @@ A *channel layer* must provide an object with these attributes
channel to send on, as a unicode string, and the message
to send, as a serializable ``dict``.

* ``coroutine receive(channels, block=False)``, that takes a list of channel
names as unicode strings, and returns with either ``(None, None)``
or ``(channel, message)`` if a message is available. If ``block`` is True, then
it will not return a message arrives (or optionally, a built-in timeout,
but it is valid to block forever if there are no messages); if
``block`` is false, it will always return immediately. It is perfectly
valid to ignore ``block`` and always return immediately, or after a delay;
``block`` means that the call can take as long as it likes before returning
a message or nothing, not that it must block until it gets one.

* ``coroutine new_channel(pattern)``, that takes a unicode string pattern,
and returns a new valid channel name that does not already exist, by
adding a unicode string after the ``!`` or ``?`` character in ``pattern``,
and checking for existence of that name in the channel layer. The ``pattern``
must end with ``!`` or ``?`` or this function must error. If the character
is ``!``, making it a process-specific channel, ``new_channel`` must be
called on the same channel layer that intends to read the channel with
``receive``; any other channel layer instance may not receive
messages on this channel due to client-routing portions of the appended string.
* ``coroutine receive(channel)``, that takes a single channel name and returns
the next received message on that channel.

* ``coroutine new_channel()``, which returns a new process-specific channel
that can be used to give to a local coroutine or receiver.

* ``MessageTooLarge``, the exception raised when a send operation fails
because the encoded message is over the layer's size limit.
Expand Down

0 comments on commit 6579c0f

Please sign in to comment.