Closed sehz closed 4 years ago
The test client first does TCP connect, then TLS connect, and then wraps the stream in Framed
. That seems correct to me.
But the test server first does TCP accept, then wraps the stream in Framed
, and finally does TLS accept. But I think it should first do TLS accept and then wrap it in Framed
. Is that the problem?
I removed framed from test code to reduce confusion. Note that server doesn't do any TLS, it's proxy that perform TLS termination and forward non TLS packets to server and reverse send back to client
Thank you, that helps a bit. Still, I feel lost in the code - there's a lot going on and I find it hard to identify where the problematic part actually is. Do you think we could shrink the code further, hopefully so that it fits into a single file? Also, can we replace fluvio-future
with async-net
?
Also, I've been running into some issues here: https://github.com/nats-io/nats.rs/pull/70#issuecomment-702246138
I wonder if this is a problem with rustls
. Maybe it'd be worth trying to replace async-tls
with async-native-tls
.
I doubt this is issue with rustls
. Similar test works fine without proxy (between TLS server and client).
I have update the test code to use async-net
and copy the code from library to make easier to understand
I replaced async-net
with tokio
and am getting the exact same behavior, which makes me believe it is indeed an issue with rustls
, or maybe even async-tls
. :)
That's interesting. Or maybe it's issue with copy
method?
Here is code for TlsStream
: https://github.com/async-rs/async-tls/blob/master/src/server.rs. Anything obvious? I can open issue on that repo
It's not the copy
method. I just switched to tokio::io::copy()
and nothing changed.
By the way, what OS are you using? I'm on macOS.
This was tested on linux ubuntu
but I also tested on Mac as well
I'm going to close this since the issue seems to be somewhere else, but keep me posted if you find something new!
After trying various combinations, found out that rustls
or async-tls
freezes when spawn
is used. It works when zip
is used. Unfortunately, other parts of code needs to use spawn
.
Fortunately, async-native-tls
works.
Thanks for troubleshooting this issue.
I have a simple TLS proxy which is using
futures_lite::io::copy
to copy source to dest and dest to source. The test does 10 iteration of sending message to between client and server. However, only first iteration works, during second iteration, client send seems to be blockTo reproduce this:
In trace mode, log shows following: