Closed povilasb closed 6 years ago
With too short timeouts connections might be prematurily dropped - especially with manual tests.
Also, note that this change indicates duplicate code. It would be really easy to extract it. I simply wonder how to deal with different error types:
channel .map_err(TcpRendezvousConnectError::ChannelRead) .next_or_else(|| TcpRendezvousConnectError::ChannelClosed) .with_timeout( Duration::from_secs(RENDEZVOUS_INFO_EXCHANGE_TIMEOUT_SEC), &handle1 ) .and_then(|opt| opt.ok_or(TcpRendezvousConnectError::ChannelTimedOut))
In case of UDP code is identical except that errors are of UdpRendezvousConnectError type.
UDP
UdpRendezvousConnectError
In terms of de-duplication you could move RENDEZVOUS_INFO_EXCHANGE_TIMEOUT_SEC up to a higher module. But I think it's fine the way it is.
RENDEZVOUS_INFO_EXCHANGE_TIMEOUT_SEC
I meant the whole code snippet, not only the constant :)
With too short timeouts connections might be prematurily dropped - especially with manual tests.
Also, note that this change indicates duplicate code. It would be really easy to extract it. I simply wonder how to deal with different error types:
In case of
UDP
code is identical except that errors are ofUdpRendezvousConnectError
type.