jonhoo / async-bincode Goto Github PK

Currently poll_close calls poll_flush on every call (see writer.rs:184). Some other implementations of AsyncWrite (e.g. async-compression) expect that poll_flush is not called after poll_close is called for the first time. Should we make the call to poll_flush in this crate conditional, or should we fix the external implementations?

I noticed this library exposes the futures_sink::Sink trait instead of the futures::sink::Sink trait. Unlike the latter, the former seems to not support futures::sink::SinkExt, which provides actual async methods for dumping things in, and there doesn't seem to be an equivalent convenience trait.

Is there currently a supported way to write to these in async contexts, by awaiting on some future, without directly interacting with the poll_ interface (and therefore having to manually manage polling/wakeups)?

it's very hard to understand how to use this crate.

bincode allows limiting the memory usage of deserialized objects, and async-bincode should probably provide a facility for this as well. Without it, attackers are able to consume up to 8GB of RAM (2* 2^32 bytes, once for the buffer, the other for the deserialized message).

In addition, on 32bit platforms, the calculation of the needed buffer size is prone to an overflow. As far as I can see, this is not actually problematic as it just causes the deserialization to fail. The memory exhaustion attack due to being unable to limit memory consumed for buffers is probably the worse vector on these platforms.

Was curious whether this relied on anything requiring an OS or if it could run on bare metal, specifically a wasm-unknown-unknown target. On the surface, it sounded like it just relied on futures, which do work in wasm, given an executor compatible with wasm.

But the file src/futures.rs uses std::task so I'm guessing not?