-
Notifications
You must be signed in to change notification settings - Fork 182
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
feat: Add Connector trait #518
Conversation
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.
I am concerned about how this might interact with TLS.
Maybe the example could do both TLS and connect()?
Sorry I didn't understand you. Do you mean that the I don't think it's a good idea to abstract |
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.
Overall I'm really positive to this abstraction, however, I want to tie it to the ReadWrite
trait instead of working with std::net::TcpStream
directly.
That potentially makes the task a lot harder, because it has wider ramifications for the handling of set_read_timeout
as well as some potentially tricky trait bounds to work out.
I've been redirected here from #692. My requirement is pretty simple: Set the local bind interface address before establishing the connection, something that It's probably a good idea to start summarising everything and document it in one go before jumping to a propoal. Reading through the comments above there seem to be two candidate approaches with different tradeoffs and a set of desired features. I'll start with the desired features (aka constraints):
So far, there are two proposed approaches with partial coverage of these constraints:
TL;DR of the two approaches:
@algesten (and others), kindly let me know where I'm going wrong and what my misunderstandings are: I've only stared at the code for 20 minutes :-). |
@amunra I think you captured it well! I think |
Are you referring to this? pub(crate) fn set_read_timeout(&self, timeout: Option<Duration>) -> io::Result<()> {
if let Some(socket) = self.socket() {
socket.set_read_timeout(timeout)
} else {
Ok(())
}
} I don't really see how it would be possible to bolt timeouts onto the For approach |
I've taken a quick look at what would be involved in This is enough to compile the main code, but not the tests and doesn't even introduce a connnector trait yet. Personally, I feel like sticking to TCP (i.e. implementing I think @algesten I'd appreciate your thoughts. |
Fair enough. Let's go with the pragmatic choice, A1. |
@zu1k, I wonder if it would make sensible to rename the trait to |
It should be so. |
A variant of this is done in 3.x |
I need to get a tcpStream established from a specific source IP, but I didn't find a proper
bind_connect
implementation inureq
.I checked the historical issue and found a lot of discussions on related content. #301 #419 #251
At the beginning, I added the
bind_connect
implementation toureq
, but I quickly relized thatureq
needs to be kept lightweight, and there may be similar requirements in the future, such as establishing connections from socks files, or other special requirements, so finally I abstracted a most basic implementation of theConnector
trait, and implementedBindConnector
based on this.The definition of the
Connector
trait is the same as theconnect
andconnect_timeout
of stdTcpStream
. I think it may need to be improved according to the needs in the future, but it should be enough for now.Signed-off-by: zu1k [email protected]