<?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="4f5bb0902c2fe317">
        <source>Detect SSL __example__</source>
        <target state="needs-translation">Detect SSL __example__</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="864b4b349e2b7024">
        <source>In this example we will build a simple function to detect the presence of the [@https://tools.ietf.org/html/rfc2246#section-7.4 TLS client handshake] given an input buffer sequence. Then we build on the example by adding a synchronous stream algorithm. Finally, we implement an asynchronous detection function using a composed operation. This SSL detector may be used to allow a server to accept both TLS and plain (unencrypted) connections at the same port.</source>
        <target state="needs-translation">In this example we will build a simple function to detect the presence of the [@https://tools.ietf.org/html/rfc2246#section-7.4 TLS client handshake] given an input buffer sequence. Then we build on the example by adding a synchronous stream algorithm. Finally, we implement an asynchronous detection function using a composed operation. This SSL detector may be used to allow a server to accept both TLS and plain (unencrypted) connections at the same port.</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="531a30530f2ed337">
        <source>Here is the declaration for a function template to detect the SSL client handshake. The function accepts any object whose type meets the requirements of __ConstBufferSequence__. This gives callers flexibility to use a buffer object whose behavior is appropriate to the task.</source>
        <target state="needs-translation">Here is the declaration for a function template to detect the SSL client handshake. The function accepts any object whose type meets the requirements of __ConstBufferSequence__. This gives callers flexibility to use a buffer object whose behavior is appropriate to the task.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">20</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d4173c2c129d6257">
        <source>The algorithm examines the buffer starting from the beginning, and performs a series of qualifying checks against the TLS specification. When not enough data exists to be certain, the returned value of `boost::indeterminate` informs the caller to read more data into the buffer. The function definition for the declaration above follows:</source>
        <target state="needs-translation">The algorithm examines the buffer starting from the beginning, and performs a series of qualifying checks against the TLS specification. When not enough data exists to be certain, the returned value of `boost::indeterminate` informs the caller to read more data into the buffer. The function definition for the declaration above follows:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">27</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7d14e22f77bb76ea">
        <source>The detection function above is suitably generic and targeted in focus that it may be used as a building block to create higher level abstractions. Our goal is to create a ['stream algorithm]: a function which is invoked with a stream, that reads or writes (or both) to achieve a purpose. In this case, to detect the TLS client handshake. Stream algorithms may be synchronous or asynchronous. Because synchronous algorithms are easier to write, we start there. Then we build the asynchronous version, trying to model it similarly to make reasoning about it easier.</source>
        <target state="needs-translation">The detection function above is suitably generic and targeted in focus that it may be used as a building block to create higher level abstractions. Our goal is to create a ['stream algorithm]: a function which is invoked with a stream, that reads or writes (or both) to achieve a purpose. In this case, to detect the TLS client handshake. Stream algorithms may be synchronous or asynchronous. Because synchronous algorithms are easier to write, we start there. Then we build the asynchronous version, trying to model it similarly to make reasoning about it easier.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">35</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="322c01428fddc1d0">
        <source>The synchronous version is implemented thusly:</source>
        <target state="needs-translation">The synchronous version is implemented thusly:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">44</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="589df143e1fd069b">
        <source>Now that we have the synchronous version, we can attempt to model the asynchronous version similarly. A function which launches an asynchronous operation is called an ['initiating function].  While the synchronous version above produces an error code through an output parameter, the asynchronous version delivers the error code to a completion handler or other custom mechanism defined by the completion token. The signature of the initiating function reflects these differences.</source>
        <target state="needs-translation">Now that we have the synchronous version, we can attempt to model the asynchronous version similarly. A function which launches an asynchronous operation is called an ['initiating function].  While the synchronous version above produces an error code through an output parameter, the asynchronous version delivers the error code to a completion handler or other custom mechanism defined by the completion token. The signature of the initiating function reflects these differences.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">48</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="92d751194b6626c6">
        <source>First we declare the initiating function and document the requirements, parameters, preconditions, and effects:</source>
        <target state="needs-translation">First we declare the initiating function and document the requirements, parameters, preconditions, and effects:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">56</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7f9be6bfd90b5451">
        <source>There are two additional components required to implement the initiating function:</source>
        <target state="needs-translation">There are two additional components required to implement the initiating function:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">61</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6d465817c32d9e78">
        <source>* An intermediate completion handler, called the "composed operation"</source>
        <target state="needs-translation">* An intermediate completion handler, called the "composed operation"</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">64</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b5093723a23d57aa">
        <source>* An "initiation" function object which when invoked with parameters</source>
        <target state="needs-translation">* An "initiation" function object which when invoked with parameters</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">69</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e6d9f6aca087fd80">
        <source>Here we forward declare the composed operation type, and provide the definition of the initiation function object. They are placed in the `detail` namespace since they should not be public:</source>
        <target state="needs-translation">Here we forward declare the composed operation type, and provide the definition of the initiation function object. They are placed in the `detail` namespace since they should not be public:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">73</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3ac44421e9e50e1a">
        <source>The initiating function definition itself is straightforward. We perform type checking on the parameters, and then let `net::async_initiate` capture the parameter list along with a copy of our initiation function object. Depending on the specialization of `async_result` for the type of `CompletionToken`, the initiation function may be invoked immediately. Alternatively, it may be invoked later, after the initiating function returns. This is known as "lazy execution," and allows efficient and expressive abstractions to be written.</source>
        <target state="needs-translation">The initiating function definition itself is straightforward. We perform type checking on the parameters, and then let `net::async_initiate` capture the parameter list along with a copy of our initiation function object. Depending on the specialization of `async_result` for the type of `CompletionToken`, the initiation function may be invoked immediately. Alternatively, it may be invoked later, after the initiating function returns. This is known as "lazy execution," and allows efficient and expressive abstractions to be written.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">79</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="46f94c0e34c19152">
        <source>Now we will declare our composed operation. There is a considerable amount of necessary boilerplate to get this right, but the result is worth the effort.</source>
        <target state="needs-translation">Now we will declare our composed operation. There is a considerable amount of necessary boilerplate to get this right, but the result is worth the effort.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">90</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="219072f07d7409ef">
        <source>The boilerplate is all done, and now we need to implement the function call operator that turns this composed operation a completion handler with the signature `void(error_code, std::size_t)` which is exactly the signature needed when performing asynchronous reads. This function is a transformation of the synchronous version of `detect_ssl` above, but with the inversion of flow that characterizes code written in the callback style:</source>
        <target state="needs-translation">The boilerplate is all done, and now we need to implement the function call operator that turns this composed operation a completion handler with the signature `void(error_code, std::size_t)` which is exactly the signature needed when performing asynchronous reads. This function is a transformation of the synchronous version of `detect_ssl` above, but with the inversion of flow that characterizes code written in the callback style:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">96</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="85a06eca4c8db315">
        <source>The examples [path_link example/advanced/server/advanced_server.cpp advanced-server] and [path_link example/advanced/server-flex/advanced_server_flex.cpp advanced-server-flex] use this SSL detection function.</source>
        <target state="needs-translation">The examples [path_link example/advanced/server/advanced_server.cpp advanced-server] and [path_link example/advanced/server-flex/advanced_server_flex.cpp advanced-server-flex] use this SSL detection function.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">106</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
    </body>
  </file>
</xliff>
