mirror of
https://github.com/tokio-rs/tokio.git
synced 2025-09-25 12:00:35 +00:00

This refactors I/O registration in a few ways: - Cleans up the cached readiness in `PollEvented`. This cache used to be helpful when readiness was a linked list of `*mut Node`s in `Registration`. Previous refactors have turned `Registration` into just an `AtomicUsize` holding the current readiness, so the cache is just extra work and complexity. Gone. - Polling the `Registration` for readiness now gives a `ReadyEvent`, which includes the driver tick. This event must be passed back into `clear_readiness`, so that the readiness is only cleared from `Registration` if the tick hasn't changed. Previously, it was possible to clear the readiness even though another thread had *just* polled the driver and found the socket ready again. - Registration now also contains an `async fn readiness`, which stores wakers in an instrusive linked list. This allows an unbounded number of tasks to register for readiness (previously, only 1 per direction (read and write)). By using the intrusive linked list, there is no concern of leaking the storage of the wakers, since they are stored inside the `async fn` and released when the future is dropped. - Registration retains a `poll_readiness(Direction)` method, to support `AsyncRead` and `AsyncWrite`. They aren't able to use `async fn`s, and so there are 2 reserved slots for those methods. - IO types where it makes sense to have multiple tasks waiting on them now take advantage of this new `async fn readiness`, such as `UdpSocket` and `UnixDatagram`. Additionally, this makes the `io-driver` "feature" internal-only (no longer documented, not part of public API), and adds a second internal-only feature, `io-readiness`, to group together linked list part of registration that is only used by some of the IO types. After a bit of discussion, changing stream-based transports (like `TcpStream`) to have `async fn read(&self)` is punted, since that is likely too easy of a footgun to activate. Refs: #2779, #2728
71 lines
1.8 KiB
Rust
71 lines
1.8 KiB
Rust
//! An UDP echo server that just sends back everything that it receives.
|
|
//!
|
|
//! If you're on Unix you can test this out by in one terminal executing:
|
|
//!
|
|
//! cargo run --example echo-udp
|
|
//!
|
|
//! and in another terminal you can run:
|
|
//!
|
|
//! cargo run --example connect -- --udp 127.0.0.1:8080
|
|
//!
|
|
//! Each line you type in to the `nc` terminal should be echo'd back to you!
|
|
|
|
#![warn(rust_2018_idioms)]
|
|
|
|
use std::error::Error;
|
|
use std::net::SocketAddr;
|
|
use std::{env, io};
|
|
use tokio::net::UdpSocket;
|
|
|
|
struct Server {
|
|
socket: UdpSocket,
|
|
buf: Vec<u8>,
|
|
to_send: Option<(usize, SocketAddr)>,
|
|
}
|
|
|
|
impl Server {
|
|
async fn run(self) -> Result<(), io::Error> {
|
|
let Server {
|
|
socket,
|
|
mut buf,
|
|
mut to_send,
|
|
} = self;
|
|
|
|
loop {
|
|
// First we check to see if there's a message we need to echo back.
|
|
// If so then we try to send it back to the original source, waiting
|
|
// until it's writable and we're able to do so.
|
|
if let Some((size, peer)) = to_send {
|
|
let amt = socket.send_to(&buf[..size], &peer).await?;
|
|
|
|
println!("Echoed {}/{} bytes to {}", amt, size, peer);
|
|
}
|
|
|
|
// If we're here then `to_send` is `None`, so we take a look for the
|
|
// next message we're going to echo back.
|
|
to_send = Some(socket.recv_from(&mut buf).await?);
|
|
}
|
|
}
|
|
}
|
|
|
|
#[tokio::main]
|
|
async fn main() -> Result<(), Box<dyn Error>> {
|
|
let addr = env::args()
|
|
.nth(1)
|
|
.unwrap_or_else(|| "127.0.0.1:8080".to_string());
|
|
|
|
let socket = UdpSocket::bind(&addr).await?;
|
|
println!("Listening on: {}", socket.local_addr()?);
|
|
|
|
let server = Server {
|
|
socket,
|
|
buf: vec![0; 1024],
|
|
to_send: None,
|
|
};
|
|
|
|
// This starts the server task.
|
|
server.run().await?;
|
|
|
|
Ok(())
|
|
}
|