From d573c7f8db5f8dfb54b0da98edd8d99ed78a9710 Mon Sep 17 00:00:00 2001
From: Benjamin Saunders <ben.e.saunders@gmail.com>
Date: Sat, 22 May 2021 13:52:18 -0700
Subject: [PATCH] Misc. doc fixes

---
 quinn-proto/src/config.rs |  5 +++--
 quinn/src/recv_stream.rs  | 19 +++----------------
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/quinn-proto/src/config.rs b/quinn-proto/src/config.rs
index 877bd01a5..b8ae5102b 100644
--- a/quinn-proto/src/config.rs
+++ b/quinn-proto/src/config.rs
@@ -492,9 +492,10 @@ where
         self
     }
 
-    /// Maximum number of incoming connections to buffer.
+    /// Maximum number of simultaneous connections to accept.
     ///
-    /// Accepting a connection removes it from the buffer, so this does not need to be large.
+    /// New incoming connections are only accepted if the total number of incoming or outgoing
+    /// connections is less than this. Outgoing connections are unaffected.
     pub fn concurrent_connections(&mut self, value: u32) -> &mut Self {
         self.concurrent_connections = value;
         self
diff --git a/quinn/src/recv_stream.rs b/quinn/src/recv_stream.rs
index cbf7e3ba9..cf6c1c18c 100644
--- a/quinn/src/recv_stream.rs
+++ b/quinn/src/recv_stream.rs
@@ -16,13 +16,10 @@ use crate::{connection::ConnectionRef, VarInt};
 /// A stream that can only be used to receive data
 ///
 /// `stop(0)` is implicitly called on drop unless:
-/// - A variant of [`ReadError`] has been emitted by [`read()`], [`read_exact()`] or [`read_unordered()`]
+/// - A variant of [`ReadError`] has been yielded by a read call
 /// - [`stop()`] was called explicitly
 ///
 /// [`ReadError`]: crate::ReadError
-/// [`read()`]: RecvStream::read
-/// [`read_exact()`]: RecvStream::read_exact
-/// [`read_unordered()`]: RecvStream::read_unordered
 /// [`stop()`]: RecvStream::stop
 #[derive(Debug)]
 pub struct RecvStream<S>
@@ -53,16 +50,6 @@ where
     /// Read data contiguously from the stream.
     ///
     /// Yields the number of bytes read into `buf` on success, or `None` if the stream was finished.
-    ///
-    /// Applications involving bulk data transfer should consider using unordered reads for
-    /// improved performance.
-    ///
-    /// # Panics
-    /// - If used after [`read_unordered()`] on the same stream.
-    ///   This is forbidden because an unordered read could consume a segment of data from a
-    ///   location other than the start of the receive buffer, making it impossible for future
-    ///
-    /// [`read_unordered()`]: RecvStream::read_unordered
     pub fn read<'a>(&'a mut self, buf: &'a mut [u8]) -> Read<'a, S> {
         Read {
             stream: self,
@@ -117,8 +104,8 @@ where
     /// offset in the stream. If `ordered` is `true`, the chunk's offset will be immediately after
     /// the last data yielded by `read()` or `read_chunk()`. If `ordered` is `false`, segments may
     /// be received in any order, and the `Chunk`'s `offset` field can be used to determine
-    /// ordering in the caller. Unordered reads have reduced overhead and higher throughput, and
-    /// should therefore be preferred when applicable.
+    /// ordering in the caller. Unordered reads are less prone to head-of-line blocking within a
+    /// stream, but require the application to manage reassembling the original data.
     ///
     /// Slightly more efficient than `read` due to not copying. Chunk boundaries do not correspond
     /// to peer writes, and hence cannot be used as framing.