feedc0de/boost_beast
1
0
Fork 0
forked from boostorg/beast
Code Pull Requests Activity
Files
04887c49e011eb13e4798e8d0fafb87e5aa7fba6
boost_beast/doc/qbk/06_websocket.qbk

39 lines
1.4 KiB
Plaintext
Raw Normal View History

Documentation work
2017-06-03 18:40:28 -07:00
[/
Copyright (c) 2013-2017 Vinnie Falco (vinnie dot falco at gmail dot com)
Distributed under the Boost Software License, Version 1.0. (See accompanying
file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
]
Documentation work
2017-06-16 19:27:00 -07:00
[section Using WebSocket]
Documentation work
2017-06-03 18:40:28 -07:00
The WebSocket Protocol enables two-way communication between a client
running untrusted code in a controlled environment to a remote host that has
opted-in to communications from that code. The protocol consists of an opening
handshake followed by basic message framing, layered over TCP. The goal of
this technology is to provide a mechanism for browser-based applications
needing two-way communication with servers without relying on opening multiple
HTTP connections.
Beast provides developers with a robust WebSocket implementation built on
Boost.Asio with a consistent asynchronous model using a modern C++ approach.
[note
Documentation work
2017-06-07 16:30:49 -07:00
This documentation assumes familiarity with __Asio__ and
the protocol specification described in __rfc6455__.
Sample code and identifiers appearing in this section is written
as if these declarations are in effect:
[ws_snippet_1]
Documentation work
2017-06-03 18:40:28 -07:00
]
Refactor chunked-encoding serialization: New buffer sequence classes are provided to allow full control over the serialization of chunk-encoded message payloads: * chunk_header A ConstBufferSequence representing the chunk header. It includes a hexadecimal-encoded size, an optional set of chunk extensions, and the trailing CRLF required to denote the end of the chunk header. This allows the caller to manually serialize the chunk body in one or more calls to a stream output function. The caller must also output an object of type `chunk_crlf` to the stream to indicate the end of the chunk body. * chunk_crlf A small ConstBufferSequence that simply represents the two character sequence "\r\n" (CRLF). This is needed for the case where the caller wants to output a chunk body as a series of buffers (i.e. "chunking a chunk"). * chunk_body A ConstBufferSequence representing a complete chunk. This includes the size, an optional set of chunk extensions, a caller provided buffer containing the body, and the required CRLF that follows. * chunk_final A ConstBufferSequence representing a final chunk. It includes an optional set of caller-provided field trailers * chunk_extensions A container for building a set of chunk extensions to use during serialization. The use of the container is optional, callers may provide their own buffer containing a correctly formatted set of chunk extensions, or they may use their own convenience container which meets the requirements. The basic_fields container is modified to allow construction outside the context of a message. The container can be used to provide trailers to `chunk_final`. Actions Required: * Remove references to ChunkDecorators. Use the new chunk-encoding buffer sequences to manually produce a chunked payload body in the case where control over the chunk-extensions and/or trailers is required.
2017-07-09 20:09:30 -07:00
[include 06_websocket/1_streams.qbk]
[include 06_websocket/2_connect.qbk]
[include 06_websocket/3_client.qbk]
[include 06_websocket/4_server.qbk]
[include 06_websocket/5_messages.qbk]
[include 06_websocket/6_control.qbk]
[include 06_websocket/7_notes.qbk]
Documentation work
2017-06-03 18:40:28 -07:00
[endsect]
Copy Permalink