Closed vorner closed 4 years ago
That's currently provided through mio
, each Device
implements mio::Evented
which allows it to be used from tokio
without doing anything tokio
only.
What would be the difference with implementing tokio::Sink
and tokio::Stream
directly?
I might be missing something, but last time I looked at how Evented
is used in tokio with PollEvented
, it required quite a large amount of boilerplate code. So, the difference would be putting this boilerplate code into the crate itself so it can be reused, possibly behind a feature gate.
As a slightly related side note, when I discussed my code on the tokio gitter, I was told the Read
and Write
(and, in context of tokio, AsyncRead
and AsyncWrite
) traits aren't the best ones, because they assume the underlying object is stream of bytes, not bunch of discrete messages ‒ things like Write::write_all
or Read::bytes
make no sense in context of a TUN device that returns packets.
In that sense, having a Stream
of packets seems like more natural API for that than AsyncRead
provided by PollEvented
. But having a recv
method which returns a future, or a framed
method, that takes a Codec
and produces a stream of some messages, would make sense too.
That's a good point, I'd be fine with a feature-gated tokio
implementation alongside the mio
one.
Hello
As mentioned in #4, I just created a „competing“ crate, whithout the intention to compete with anyone. I have a minimal implementation for async with tokio, which I wanted to extend in the future. It works by turning the interface object into an async object (which no longer supports all the fancy things like getting the name) that implements
Sink
andStream
.So, I was thinking, instead of trying to compete, would it make sense if I ported that async wrapper to this crate?