-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the reuse for UNIX stream DNS lookup. #567
Conversation
ee68d29
to
4669527
Compare
My compiler complains that this commit cannot be found: https://github.com/zonyitoo/tokio/commit/47b76a5a |
I got the compilation error as well, you may have to rebase to an old commit. |
Our UNIX stream based DNS lookup doesn't support connection reuse.
4669527
to
c8fc85c
Compare
Just ignore it. I will fix it until tokio's PR was merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can confirm this fixes everything. (I thought I was going to implement a DNS cache in shadowsocks-android for a moment so thank god!)
The UNIX stream should report errors if the endpoint have been closed. Hmm.. Why it is the cause of shadowsocks/shadowsocks-android#2751 ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. But why?
Our android UNIX stream resolver doesn't support connection reuse yet. I will use this PR to create a new release of shadowsocks-android as a hotfix. But for now, I think it's okay to keep it open for shadowsocks-rust. |
There is no reason to support connection reuse on local sockets since the delay is negligible. Currently, shadowsocks-android should close the socket (syscall EDIT: Holding a local socket open also wastes system resources methinks. |
Well, you are right about the cost of creating unix local stream is negligible. I am Ok with this PR, but I still cannot understand why it cause that issue. Currently the implementation will open a new client if the connection have been lost due to |
Maybe we merge this and figure out the retry later? 😛 |
I am worrying about if there are any issues in this connection management strategy, then it will also affect TCP and UDP DNS clients. |
^ |
Our UNIX stream based DNS lookup doesn't support connection reuse.