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.

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

fix(quic): use Provider::send_to for UDP datagram #28

Merged
merged 2 commits into from
Jul 4, 2023

Conversation

mxinden
Copy link

@mxinden mxinden commented Jun 28, 2023

Description

Links to any relevant issues

Addresses libp2p#3454 (comment).

Open Questions

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

Comment on lines 64 to 74
fn from_std_udp_socket(socket: std::net::UdpSocket) -> io::Result<Self::UdpSocket> {
Ok(socket.into())
}

fn send_to<'a>(
udp_socket: &'a Self::UdpSocket,
buf: &'a [u8],
target: std::net::SocketAddr,
) -> BoxFuture<'a, io::Result<usize>> {
udp_socket.send_to(buf, target).boxed()
}
Copy link

@thomaseizinger thomaseizinger Jun 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of two functions, we could also make one function that accepts an std::net::UdpSocket, converts it internally to the runtime-specific one, sends the packet and returns the socket.

That would avoid the associated type and reduce this to one function that needs to be implemented.

@mxinden
Copy link
Author

mxinden commented Jul 2, 2023

Appreciate the reviews @kpp and @thomaseizinger.

Latest commit applies the above suggestions and hides the Tokio and async-std types.

Mind taking another look?

target: std::net::SocketAddr,
) -> BoxFuture<'a, io::Result<usize>> {
Box::pin(async move {
async_std::net::UdpSocket::from(udp_socket.try_clone()?)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When does try_clone fail? The docs don't mention anything.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding:

I am assuming that you wonder whether we can do without propagating the error. Given that we already need a way to propagate the error from send_to, I don't think we should apply any special treatment to the error from try_clone. Are you fine with that @thomaseizinger?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me! I was just wondering whether there are any specific error cases :)

Happy to keep as is!

Comment on lines +35 to 37
if let Err(e) = P::send_to(&socket, &contents, remote_addr).await {
return Error::Io(e);
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this just what ? would do?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wondered the same. Note the function signature:

async fn punch_holes<P: Provider>(socket: UdpSocket, remote_addr: SocketAddr) -> Error {

The function never returns, unless there is an Error. In words, the function returns Error and not Result<_, Error>. Thus one can not use ?.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should change it to Result<Infallible, Error>?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this in libp2p#3964 as well, can't find the concrete conversation right now. I suggest we keep as is unless you feel strongly about it @thomaseizinger.

@kpp kpp merged commit 29c575e into kpp:quic_quinn Jul 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants