Update DocFx after documentation changes.

msquicdocs/docs/Settings.html

@@ -403,6 +403,13 @@ Generally MsQuic already choses the best / most correct default values for all s
 <td>0 (FALSE)</td>
 <td>Enable sender-side ECN support.</td>
 </tr>
+<tr>
+<td>Stream Multi Receive</td>
+<td>uint8_t</td>
+<td>StreamMultiReceiveEnabled</td>
+<td>0 (FALSE)</td>
+<td>Enable multi receive support</td>
+</tr>
 </tbody>
 </table>
 <p>The types map to registry types as follows:</p>

msquicdocs/docs/Streams.html

@@ -134,7 +134,7 @@
 <p>Data is received and delivered to apps via the <code>QUIC_STREAM_EVENT_RECEIVE</code> event. The event indicates zero, one or more contiguous buffers up to the application.</p>
 <p>Typically, the buffer count is one, which means that most events will include a single buffer containing the received data.</p>
 <p>When the buffer count is 0, it signifies the reception of a QUIC frame with empty data, which also indicates the end of stream data.</p>
-<p>Currently, the maximum buffer count is 2 in the case of partial receive, where only a portion of the buffer data is consumed (as explained below). However, it is strongly advised not to assume in application code that the upper limit is always 2. This caution is important because future releases may incorporate multiple circular buffers to enhance performance, leading to potential changes in the buffer count limit.</p>
+<p>Currently, the maximum buffer count is 3 in the case of partial receive, where only a portion of the buffer data is consumed (as explained below). However, it is strongly advised not to assume in application code that the upper limit is always 3. This caution is important because future releases may change internal algorithm, leading to potential changes in the buffer count limit.</p>
 <p>The app then may respond to the event in a number of ways:</p>
 <h2 id="synchronous-vs-asynchronous">Synchronous vs Asynchronous</h2>
 <p>The app has the option of either processing the received data in the callback (synchronous) or queuing the work to a separate thread (asynchronous). If the app processes the data synchronously it must do so in a timely manner. Any significant delays will delay other QUIC processing (such as sending acknowledgments), which can cause protocol issues (dropped connections).</p>
@@ -146,6 +146,10 @@
 <p>Any value less than or equal to the initial <strong>TotalBufferLength</strong> value is allowed, including zero.</p>
 <p>Whenever a receive isn't fully accepted by the app, additional receive events are immediately disabled. The app is assumed to be at capacity and not able to consume more until further indication. To re-enable receive callbacks, the app must call <a href="api/StreamReceiveSetEnabled.html">StreamReceiveSetEnabled</a>.</p>
 <p>There are cases where an app may want to partially accept the current data, but still immediately get a callback with the rest of the data. To do this (only works in the synchronous flow) the app must return <code>QUIC_STATUS_CONTINUE</code>.</p>
+<h2 id="multi-receive-mode">Multi Receive mode</h2>
+<p>Setting <a href="Settings.html"><code>StreamMultiReceiveEnabled</code></a> an app can continue getting indicated by <code>QUIC_STREAM_EVENT_RECEIVE</code> without returning <code>QUIC_STATUS_SUCCESS</code> nor calling <a href="api/StreamReceiveComplete.html">StreamReceiveComplete</a>.</p>
+<p>This changes internal receive buffer more efficient for continuous receiving.</p>
+<p>The app need to keep track of total <code>TotalBufferLength</code> to later call <a href="api/StreamReceiveComplete.html">StreamReceiveComplete</a> appropriately.</p>
 
 </article>
 

msquicdocs/docs/api/QUIC_SETTINGS.html

@@ -137,7 +137,8 @@
             uint64_t ReliableResetEnabled                   : 1;
             uint64_t OneWayDelayEnabled                     : 1;
             uint64_t NetStatsEventEnabled                   : 1;
-            uint64_t RESERVED                               : 22;
+            uint64_t StreamMultiReceiveEnabled              : 1;
+            uint64_t RESERVED                               : 21;
 #else
             uint64_t RESERVED                               : 26;
 #endif
@@ -187,7 +188,8 @@
             uint64_t ReliableResetEnabled      : 1;
             uint64_t OneWayDelayEnabled        : 1;
             uint64_t NetStatsEventEnabled      : 1;
-            uint64_t ReservedFlags             : 59;
+            uint64_t StreamMultiReceiveEnabled : 1;
+            uint64_t ReservedFlags             : 58;
 #else
             uint64_t ReservedFlags             : 63;
 #endif
@@ -316,6 +318,9 @@
 <p><code>StreamRecvWindowUnidiDefault</code></p>
 <p>Initial stream receive flow control window size for remotely initiated unidirectional streams. If set, this value overwrites the <code>StreamRecvWindowDefault</code>.</p>
 <p><strong>Default value:</strong> 0 (no overwrite)</p>
+<p><code>StreamMultiReceiveEnabled</code></p>
+<p>Enable multi receive mode. An app can continue receiving stream data without calling <code>StreamReceiveComplete</code> for each <code>QUIC_STREAM_EVENT_RECEIVE</code> indication.</p>
+<p><strong>Default value:</strong> 0 (<code>FALSE</code>)</p>
 <h1 id="remarks">Remarks</h1>
 <p>When setting new values for the settings, the app must set the corresponding <code>.IsSet.*</code> parameter for each actual parameter that is being set or updated. For example:</p>
 <pre><code class="lang-C">QUIC_SETTINGS Settings {0};

msquicdocs/docs/api/StreamReceiveComplete.html

@@ -101,8 +101,9 @@ void
 <p><strong>TODO</strong></p>
 <h1 id="remarks">Remarks</h1>
 <p>This is an asynchronous API but can run inline if called in a callback.
-The application must ensure that one <code>StreamReceiveComplete</code> call corresponds to one <code>QUIC_STREAM_EVENT_RECEIVE</code> event.
-Duplicate <code>StreamReceiveComplete</code> calls after one <code>QUIC_STREAM_EVENT_RECEIVE</code> event are ignored silently even with different <code>BufferLength</code>.</p>
+The application, without setting <code>StreamMultiReceiveEnabled</code>, must ensure that one <code>StreamReceiveComplete</code> call corresponds to one <code>QUIC_STREAM_EVENT_RECEIVE</code> event.
+Duplicate <code>StreamReceiveComplete</code> calls after one <code>QUIC_STREAM_EVENT_RECEIVE</code> event are ignored silently even with different <code>BufferLength</code>.
+The <code>StreamMultiReceiveEnabled</code> mode doesn't follow this rule. Multiple <code>QUIC_STREAM_EVENT_RECEIVE</code> events can be indicated at once by <code>StreamReceiveComplete</code>. The application needs to keep track of accumulated <code>TotalBufferLength</code> with this mode.</p>
 <h1 id="see-also">See Also</h1>
 <p><a href="StreamOpen.html">StreamOpen</a><br>
 <a href="StreamClose.html">StreamClose</a><br>