tokio based async support #3
Conversation
|
|
||
| [features] | ||
| vendored = ["openssl/vendored"] | ||
| async = ["futures", "tokio", "tokio-openssl"] |
There was a problem hiding this comment.
I love this to be an option. Great!
| @@ -75,12 +75,12 @@ impl DtlsAcceptor { | |||
| pub fn accept<S: fmt::Debug>( | |||
There was a problem hiding this comment.
Don't we support this builder to work for async?
There was a problem hiding this comment.
done and pushed to the same branch
src/dtls_connector.rs
Outdated
|
|
||
| #[cfg(feature="async")] | ||
| #[derive(Debug)] | ||
| pub enum AsyncConnectError<S> { |
There was a problem hiding this comment.
I left it here, for a moment by purpose. The way it is now is not too elegant, and I wanted to ask you for an opinion. Actually, I can see three alternatives here:
- move AsyncConnectError to error.rs and let it be like this
- extend error::Error with another choice tokio_openssl::HandshakeError
- change both connect / async_connect error option to something like Box so it will be able to accommodate anything.
There was a problem hiding this comment.
I moved AsyncConnectError to error.rs, although alternatives mentioned above are still valid
| fn from(stream: SslStream<S>) -> Self { | ||
| DtlsStream(stream) | ||
| } | ||
| } | ||
|
|
||
|
|
||
| pub trait DtlsStreamExt<S> { |
| @@ -9,81 +9,33 @@ use std::{fmt, io}; | |||
| /// and both the server and the client are ready for receiving and sending | |||
| /// data. Bytes read from a `DtlsStream` are decrypted from `S` and bytes written | |||
| /// to a `DtlsStream` are encrypted when passing through to `S`. | |||
| pub struct DtlsStream<S>(ssl::SslStream<S>); | |||
| pub struct DtlsStream<C>(pub(crate) C); | |||
There was a problem hiding this comment.
Do we need to make this public since we have the SyncStream now
There was a problem hiding this comment.
as far as I undertsand - yes
| @@ -35,9 +35,9 @@ where | |||
| /// This corresponds to [`SSL_do_handshake`]. | |||
| /// | |||
| /// [`SSL_do_handshake`]: https://www.openssl.org/docs/manmaster/man3/SSL_do_handshake.html | |||
| pub fn handshake(self) -> Result<DtlsStream<S>, HandshakeError<S>> { | |||
| pub fn handshake(self) -> Result<SyncDtlsStream<S>, HandshakeError<S>> { | |||
There was a problem hiding this comment.
Though, how are we going to use this for async now?
There was a problem hiding this comment.
ssl::HandshakeError::WouldBlock is properly handled inside tokio_openssl, and nothing has to be done in the user code
|
|
||
| use crate::{DtlsStream, DtlsStreamExt}; | ||
|
|
||
| pub type AsyncDtlsStream<S> = DtlsStream<AsyncSslStream<S>>; |
There was a problem hiding this comment.
AsyncDtlsStream and SyncDtlsStream are the same types until used in UdpChannel. Maybe we do not have to create separate type definitions for those?
|
|
If we implement |
|
async example is now in examples/ |
|
Right now, it would be difficult to get rid of tokio dependency because we strongly depend on tokio-openssl, which, in turn, depends on tokio. This dependency is not very significant, since the only things it takes from tokio are AsyncRead, AsyncWrite, which have their counterparties in futures::io. Perhaps it should be possible to convince the tokio-openssl author to make his library more neutral. |
|
aha, this is was already discussed. So I would wait until futures-openssl will be available. |
Meanwhile, I created a prototype for tokio/async support. It seems to work in my setup (in combination with rust-async-coap). But it's far from being final.
What do you think?