<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="zh_Hans">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="ce54236394ef5b77">
        <source>Notes</source>
        <target state="needs-translation">Notes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">10</context>
        </context-group>
        <note from="developer">type: section title</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c2fa278327046f1b">
        <source>Because calls to read data may return a variable amount of bytes, the interface to calls that read data require an object that meets the requirements of __DynamicBuffer__. This concept is modeled on __streambuf__.</source>
        <target state="needs-translation">Because calls to read data may return a variable amount of bytes, the interface to calls that read data require an object that meets the requirements of __DynamicBuffer__. This concept is modeled on __streambuf__.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">12</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="06921f983e7e7a2d">
        <source>The implementation does not perform queueing or buffering of messages. If desired, these features should be provided by callers. The impact of this design is that library users are in full control of the allocation strategy used to store data and the back-pressure applied on the read and write side of the underlying TCP/IP connection.</source>
        <target state="needs-translation">The implementation does not perform queueing or buffering of messages. If desired, these features should be provided by callers. The impact of this design is that library users are in full control of the allocation strategy used to store data and the back-pressure applied on the read and write side of the underlying TCP/IP connection.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">16</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="718c3837f7d1f760">
        <source>Asynchronous Operations</source>
        <target state="needs-translation">Asynchronous Operations</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">22</context>
        </context-group>
        <note from="developer">type: heading</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a1e0c426f05196c5">
        <source>Asynchronous versions are available for all functions:</source>
        <target state="needs-translation">Asynchronous versions are available for all functions:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">24</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c3f4ecd73b627da1">
        <source>Calls to asynchronous initiation functions support the extensible asynchronous model developed by the Boost.Asio author, allowing for traditional completion handlers, stackful or stackless coroutines, and even futures:</source>
        <target state="needs-translation">Calls to asynchronous initiation functions support the extensible asynchronous model developed by the Boost.Asio author, allowing for traditional completion handlers, stackful or stackless coroutines, and even futures:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">28</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6a22e714039129af">
        <source>The example programs that come with the library demonstrate the usage of websocket stream operations with all asynchronous varieties.</source>
        <target state="needs-translation">The example programs that come with the library demonstrate the usage of websocket stream operations with all asynchronous varieties.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">34</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66f841ea8529a889">
        <source>The io_context</source>
        <target state="needs-translation">The io_context</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">37</context>
        </context-group>
        <note from="developer">type: heading</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="33d577f5ef2f9b06">
        <source>The creation and operation of the __io_context__ associated with the underlying stream is left to the callers, permitting any implementation strategy including one that does not require threads for environments where threads are unavailable. Beast WebSocket itself does not use or require threads.</source>
        <target state="needs-translation">The creation and operation of the __io_context__ associated with the underlying stream is left to the callers, permitting any implementation strategy including one that does not require threads for environments where threads are unavailable. Beast WebSocket itself does not use or require threads.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">39</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="77199f9ea254953b">
        <source>Thread Safety</source>
        <target state="needs-translation">Thread Safety</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">45</context>
        </context-group>
        <note from="developer">type: heading</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0251f3c26e043353">
        <source>Like a regular __Asio__ socket, a [link beast.ref.boost__beast__websocket__stream `stream`] is not thread safe. Callers are responsible for synchronizing operations on the socket using an implicit or explicit strand, as per the Asio documentation. The websocket stream asynchronous interface supports one of each of the following operations to be active at the same time:</source>
        <target state="needs-translation">Like a regular __Asio__ socket, a [link beast.ref.boost__beast__websocket__stream `stream`] is not thread safe. Callers are responsible for synchronizing operations on the socket using an implicit or explicit strand, as per the Asio documentation. The websocket stream asynchronous interface supports one of each of the following operations to be active at the same time:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">47</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="04522124afae919c">
        <source>* [link beast.ref.boost__beast__websocket__stream.async_read `async_read`] or [link beast.ref.boost__beast__websocket__stream.async_read_some `async_read_some`]
* [link beast.ref.boost__beast__websocket__stream.async_write `async_write`] or [link beast.ref.boost__beast__websocket__stream.async_write_some `async_write_some`]
* [link beast.ref.boost__beast__websocket__stream.async_ping `async_ping`] or [link beast.ref.boost__beast__websocket__stream.async_pong `async_pong`]
* [link beast.ref.boost__beast__websocket__stream.async_close `async_close`]</source>
        <target state="needs-translation">* [link beast.ref.boost__beast__websocket__stream.async_read `async_read`] or [link beast.ref.boost__beast__websocket__stream.async_read_some `async_read_some`]
* [link beast.ref.boost__beast__websocket__stream.async_write `async_write`] or [link beast.ref.boost__beast__websocket__stream.async_write_some `async_write_some`]
* [link beast.ref.boost__beast__websocket__stream.async_ping `async_ping`] or [link beast.ref.boost__beast__websocket__stream.async_pong `async_pong`]
* [link beast.ref.boost__beast__websocket__stream.async_close `async_close`]</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">54</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="46ba2d44f10fcbe9">
        <source>For example, the following code is produces undefined behavior, because the program is attempting to perform two simultaneous reads:</source>
        <target state="needs-translation">For example, the following code is produces undefined behavior, because the program is attempting to perform two simultaneous reads:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">59</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="74cbfe644658db0c">
        <source>However, this code is correct:</source>
        <target state="needs-translation">However, this code is correct:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">64</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c461c076c09127ee">
        <source>The implementation uses composed asynchronous operations; although some individual operations can perform both reads and writes, this behavior is coordinated internally to make sure the underlying stream is operated in a safe fashion. This allows an asynchronous read operation to respond to a received ping frame even while a user-initiated call to asynchronous write is active.</source>
        <target state="needs-translation">The implementation uses composed asynchronous operations; although some individual operations can perform both reads and writes, this behavior is coordinated internally to make sure the underlying stream is operated in a safe fashion. This allows an asynchronous read operation to respond to a received ping frame even while a user-initiated call to asynchronous write is active.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">68</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
    </body>
  </file>
</xliff>
