Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Provide access to connection Waker to datagram Endpoint #1598

Merged
merged 2 commits into from
Jan 6, 2023
Merged

Provide access to connection Waker to datagram Endpoint #1598

merged 2 commits into from
Jan 6, 2023

Commits on Dec 29, 2022

  1. Remove Default for datagram (Pre)ConnectionInfo structs 

    It doesn't make much sense for there to be default values for these, and
as more fields are added a Default may become awkward or impossible.

This removes the ability to construct these outside of s2n-quic, but
doing so is awkward if there's no reasonable default value for some of
the fields. (The next commit adds such a value for ConnectionInfo).
    @Mark-Simulacrum
    Mark-Simulacrum committed Dec 29, 2022
    Configuration menu
    Copy the full SHA
    0fcd174 View commit details
    Browse the repository at this point in the history

  2. Add Waker to datagram ConnectionInfo 

    This waker allows datagram receiver/senders to wake up the connection,
which will re-poll the connection for interest in sending. When
implementing a custom datagram Receiver which wants to schedule a reply
datagram, this Waker or something like it is necessary to indirect the
wakeup of the connection and subsequent call to the Sender's
on_transmit.

This is a waker and not a connection handle for two reasons:

* The Waker does not directly extend the lifetime of the connection,
  which avoids keeping the connection data indefinitely alive for cases
  where the Waker is stored within the Sender or Receiver.
* s2n-quic calling datagram Endpoint::new_connection doesn't have easy
  access to an application handle to the connection.

Note that applications still must retain the Connection or a Handle to
it: when the last application handle closes, the connection is also
closed, even if there are Wakers for that connection still around.

In practice this seems useful as it allows bounding the number of active
connections with an Endpoint and the extra waste of connection handles
is unlikely to be significant.
    @Mark-Simulacrum
    Mark-Simulacrum committed Dec 29, 2022
    Configuration menu
    Copy the full SHA
    675b66c View commit details
    Browse the repository at this point in the history