=doc websocket - amending streaming to streamed msgs #19945
This commit is contained in:
parent
24fc2c3134
commit
16e3e01ba2
4 changed files with 7 additions and 7 deletions
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.)
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue