CODEWITHSUNDEEP
tcptimeoutrust
Levans
Levans

Reputation: 14992

How exactly works set_timeout() on a TcpStream?

I'm working with TcpStream. The basic structure I'm working with is :

loop {
    if /* new data in the stream */ { /* handle it */ }
    /* do a lot of other stuff */
}

So set_timeout() appears to be what I need, but I'm a little puzzled about how it works. The documentation says :

This function will set a timeout for all blocking operations (including reads and writes) on this stream. The timeout specified is a relative time, in milliseconds, into the future after which point operations will time out. This means that the timeout must be reset periodically to keep it from expiring.

So I would expect to have to reset the timeout each time before checking if new data is available, otherwise I would only have Err(TimeOut) after some time.

But it appears not to be the case : actually if I set a very low timeout (like 10 ms) once and for all, the loop does exactly what I want. It returns new data if there is some, and returns Err(TimeOut) if there is none.

Am I misunderstanding the documentation ? Is it safe for me to use this behavior ?

Upvotes: 4

Views: 990

Answers (1)

Steffen Ullrich
Steffen Ullrich

Reputation: 123320

I would have expected it to work like a socket timeout, like you have as the property for sockets in most operating systems and which is available from with the programming languages with SO_TIMEOUT or similar things. With such socket timeout the timer will be started whenever you start a blocking operation on the socket, like read, write, connect. Either the operation will succeed within the time frame or the timer will be triggered and the operation fail because of a timeout. The timeout is a property of the socket and not of the operation, so there is no need to set it again before each operation.

But according to the documentation Rust implemented a completely different thing. If I interpret the documentation correctly they don't set a timeout per operation, but instead set a deadline for all operations of this type on the socket. That is, when the timer is set up to 10 seconds you can have multiple reads within this time but if there is still a read active after 10 seconds it will be stopped.

When one is used to work with socket timeouts in other languages this behavior is not the expected one and it looks like the Rust developers have similar objections to this (experimental) API. In https://github.com/rust-lang/rust/issues/15802 they suggest to rename these kind of functions from set..timeout to set..deadline to make the name reflect the behavior.

Upvotes: 1

Related Questions