For reasons explained in the readme (copied below) I've just published futures-udp which provides Stream & Sink.

Right now, it is nightly-only as it uses never_type (already finished the FCP) and bool_to_result (just started FCP). This should hopefully change in the next few weeks given they are both in the final stages of stabilisation ...

I'd love to hear any comments & feedback, particularly on the API.

from the docs:

Runtime agnostic, non-blocking, non-exclusive async UDP networking.

futures-udp provides two key structs:

• UdpStream for reading data from a UDP Socket
• UdpSink for sending data via a UDP Socket

These structs implement the futures-rs traits Stream & Sink respectively but are tested
and known to work with both tokio & futures-rs runtimes. (tokio tests performed in a
downstream crate, I'll add them here soon so to make sure this never breaks)

Why?

• Working with a bare UdpSocket is "a bit hard", doing it async is "a bit more hard".
  Adding Stream & Sink semantics makes it "nice".
• I usually don't want to be forced to bring tokio into my dependency tree unless I want
  to use it as my runtime. I think the runtime choice should be left to the final binary.
• futures-rs is a lot lighter weight and provided by rust-lang, so I chose that for the base
  traits. They are cross-compatible with tokio.
• Despite the docs futures_net::UdpSocket creates a blocking socket, which is locked
  for exclusive use. krircc/futures-net#2

Where this started

I wanted to create a simple SSDP-repeater (splurt) to allow me to run DLNA services in docker containers. I looked at the crates available and couldn't find anything that gave me a usable API for UDP where I felt confident in the code and it did what I needed. So I ended up building it myself and decided to split it out into a separate crate.

1 post - 1 participant

Read full topic