Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor(server): remove ServerConnectionIdGenerator
A `neqo_transport::Server` manages multiple `neqo_transport::Connection`s. A `Server` keeps a `HashMap` of all `Connection`s, indexed by `ConnectionId`. Indexing by `ConnectionId` is difficult as: - The `ConnectionId` is not known before constructing the connection. - The `ConnectionId` might change throughout the lifetime of a connection. Previously the index was kept up-to-date through a wrapper around the `ConnectionIdGenerator` provided to a `Connection` by a `Server`. This wrapper would be provided a shared reference to the `Server`s `HashMap` of `Connection`s. Whenever the `Server` would `process` a `Connection` and that `Connection` would generate a new `ConnectionId` via `ConnectionIdGenerator::generate_cid`, the wrapped `ConnectionIdGenerator` would also insert the `Connection` keyed by the new `ConnectionId` into the `Server`'s `HashMap` of `Connection`s. This has two problems: - Complexity through indirection where a `Connection` owned by a `Server` can indirectly mutate the `Server` through the provided wrapped `ConnectionIdGenerator` having access to the `Server`'s set of `Connection`s. - Double `RefCell` borrow e.g. when a `Server` would iterate its `Connection`s, process each, where one of them might generate a new `ConnectionId` via the provided `ConnectionIdGenerator`, which in turn would insert the `Connection` into the currently iterated set of `Connection`s of the `Server`. This commit replaces the `HashMap<ConnectionId, Connection>` of the `Server` with a simple `Vec<Connection>`. Given the removal of the index, the `ConnectionIdGenerator` wrapper (i.e. `ServerConnectionIdGenerator`) is no longer needed and removed and thus the shared reference to the `Server`s `Connection` `HashMap` is no longer needed and thus the above mentioned double borrow is made impossible. Downside to the removal of the index by `ConnectionId` is a potential performance hit. When the `Server` manages a large set of `Connection`s, finding the `Connection` corresponding to a `ConnectionId` (e.g. from an incoming `Datagram`) is `O(n)` (`n` equal the number of connections).
- Loading branch information