=doc websocket - amending streaming to streamed msgs #19945

This commit is contained in:
Stefano Bonetti 2016-08-09 12:10:52 +01:00 committed by Johan Andrén
parent 24fc2c3134
commit 16e3e01ba2
4 changed files with 7 additions and 7 deletions

View file

@ -28,7 +28,7 @@ HTTP result can be found in ``WebSocketUpgradeResponse.response``
Message
-------
Messages sent and received over a WebSocket can be either :class:`TextMessage` s or :class:`BinaryMessage` s and each
of those can be either strict (all data in one chunk) or streaming. In typical applications messages will be strict as
of those can be either strict (all data in one chunk) or streamed. In typical applications messages will be strict as
WebSockets are usually deployed to communicate using small messages not stream data, the protocol does however
allow this (by not marking the first fragment as final, as described in `rfc 6455 section 5.2`__).
@ -37,7 +37,7 @@ __ https://tools.ietf.org/html/rfc6455#section-5.2
The strict text is available from ``TextMessage.getStrictText`` and strict binary data from
``BinaryMessage.getStrictData``.
For streaming messages ``BinaryMessage.getStreamedData`` and ``TextMessage.getStreamedText`` is used to access the data.
For streamed messages ``BinaryMessage.getStreamedData`` and ``TextMessage.getStreamedText`` is used to access the data.
In these cases the data is provided as a ``Source<ByteString, NotUsed>`` for binary and ``Source<String, NotUsed>``
for text messages.

View file

@ -40,7 +40,7 @@ the notion of a "strict" message to represent cases where a whole message was re
When receiving data from the network connection the WebSocket implementation tries to create a strict message whenever
possible, i.e. when the complete data was received in one chunk. However, the actual chunking of messages over a network
connection and through the various streaming abstraction layers is not deterministic from the perspective of the
application. Therefore, application code must be able to handle both streaming and strict messages and not expect
application. Therefore, application code must be able to handle both streamed and strict messages and not expect
certain messages to be strict. (Particularly, note that tests against ``localhost`` will behave differently than tests
against remote peers where data is received over a physical network connection.)