Taken from the source: https://github.com/carllerche/mio/blob/getting-started/doc/getting-started.md Important: Even if we just received a ready notification, there is no guarantee that a read from the socket will succeed and not return Ok(None), so we must handle that case as well. That sounds pretty bad, maybe this case should be handled, whenever an operation is started, if the first result is the so-called Ok(None), WouldBlock currently, the operation should be cancelled. And the socket owning the pipe should be notified so it can retry or reschedule the operation.

PB: the dispatcher receiving CanSend/CanRecv events does not know if a device or a probe is 'listening'. What if several probes are interested in the readiness the same socket ?

Change doc links of versioned packaged to docs.rs, since it is easy to support several version. See https://docs.rs/about

Improvements

Reconnect interval max
Linger
Handle accept error
Req prefetch replies
Use a pool for payloads and buffers (if any)
Find something more efficient than a channel for sending replies from the event loop back to the facade (a mailbox?)
INPROC transport : to be determined (rust channel's are probably doing a better work at this)