Skip to content
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

more flexible timeouts #26

Merged
merged 3 commits into from
Jul 30, 2020
Merged

more flexible timeouts #26

merged 3 commits into from
Jul 30, 2020

Conversation

Hocuri
Copy link
Collaborator

@Hocuri Hocuri commented Jul 26, 2020

Fix #22

Comment on lines 238 to 254
let read = with_timeout(this.timeout.as_ref(), reader.read_line(&mut buffer)).await?;
let read = with_timeout(timeout, reader.read_line(&mut buffer)).await?;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that this is the important part?

Comment on lines 207 to 223
async fn write(mut self: Pin<&mut Self>, string: &[u8]) -> Result<(), Error> {
async fn write(
mut self: Pin<&mut Self>,
string: &[u8],
timeout: Option<&Duration>,
) -> Result<(), Error> {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it, is it even necessary to change the timeout here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RFC 1123 recommends to use 3 minutes per TCP SEND call. We don't have such low-level access and these recommendations are outdated because TCP buffer size is variable now, but I think what they mean is:

  1. You do a UNIX write/send call asking to write 1MB to the socket, and wait for 3 minutes.
  2. Call returns, telling you that 100kb were written to the buffer.
  3. You do a send call again, asking to write 900kb to the socket, and wait for 3 minutes again.
    ...
    Essentially the write timeout of this whole operation is file size divided by TCP buffer size and multiplied by 3 minutes, so it should grow linearly with file size.

@Hocuri
Copy link
Collaborator Author

Hocuri commented Jul 27, 2020

@dignifiedquire I could fix all those Clippy warnings, but the ci here tests on Beta branch of Rust and DeltaChat runs on release branch, which one shall I take?

@dignifiedquire
Copy link
Collaborator

hmm CI is pretty broken, we should fix master first independently

self.as_mut()
.write(command.to_string().as_bytes(), timeout)
.await?;
self.read_response(timeout).await
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this uses the timeout twice, I believe the "correct" way would be

let fut = async move {
  self.as_mut().write(command.to_string().as_bytes()).await?;
  self.read_response().await
};
fut.timeout(timeout).await

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, write timeout and read timeouts are separate.

Hocuri added a commit to chatmail/core that referenced this pull request Jul 30, 2020
@Hocuri
Copy link
Collaborator Author

Hocuri commented Jul 30, 2020

hmm CI is pretty broken, we should fix master first independently

I'll do this, but the ci here runs on beta branch of Rust and DC on the release branch. They changed some naming and I have to decide for beta or release. Which one shall I take?

@dignifiedquire dignifiedquire changed the title [WIP] Flexible timeouts (for larger messages) more flexible timeouts Jul 30, 2020
@dignifiedquire dignifiedquire merged commit c167dbe into master Jul 30, 2020
@dignifiedquire dignifiedquire deleted the smtptimeout branch July 30, 2020 12:16
let mut message_bytes = Vec::new();
message_reader.read_to_end(&mut message_bytes).await?;
let mut message_bytes = Vec::new();
message_reader.read_to_end(&mut message_bytes).await?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this wrapped into timeout now? It is a completely local operation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Flexible timeouts (for larger messages)
3 participants