-
Notifications
You must be signed in to change notification settings - Fork 87
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
Wrongful IDLE timeout reset on response #300
Comments
z33ky
added a commit
to z33ky/rust-imap
that referenced
this issue
Jan 28, 2025
The code used to apply the set timeout value to the TcpStream before entering the IDLE loop. This effectively resets the timeout after receiving and handling incoming messages, which nullifies the purpose of the timeout when messages are received. This change remembers when the IDLE command is sent initially and uses that value to set the remaining time for the TcpStream timeout. This allows the IDLE loop to reconnect the IDLE connection at the appropriate time. Fixes jonhoo#300.
Ah, I see, specifically the problem is if the callback doesn't terminate during the wait period, but instead just passively consumes the responses and "continues" the IDLE. Because in that case no signal is sent to the server to indicate that the client is still active. Thanks for the PR — will take a look! And sorry for the delay :) |
z33ky
added a commit
to z33ky/rust-imap
that referenced
this issue
Feb 16, 2025
The code used to apply the set timeout value to the TcpStream before entering the IDLE loop. This effectively resets the timeout after receiving and handling incoming messages, which nullifies the purpose of the timeout when messages are received. This change remembers when the IDLE command is sent initially and uses that value to set the remaining time for the TcpStream timeout. This allows the IDLE loop to reconnect the IDLE connection at the appropriate time. Fixes jonhoo#300.
z33ky
added a commit
to z33ky/rust-imap
that referenced
this issue
Feb 16, 2025
The code used to apply the set timeout value to the TcpStream before entering the IDLE loop. This effectively resets the timeout after receiving and handling incoming messages, which nullifies the purpose of the timeout when messages are received. This change remembers when the IDLE command is sent initially and uses that value to set the remaining time for the TcpStream timeout. This allows the IDLE loop to reconnect the IDLE connection at the appropriate time. Fixes jonhoo#300.
z33ky
added a commit
to z33ky/rust-imap
that referenced
this issue
Feb 16, 2025
The code used to apply the set timeout value to the TcpStream before entering the IDLE loop. This effectively resets the timeout after receiving and handling incoming messages, which nullifies the purpose of the timeout when messages are received. This change remembers when the IDLE command is sent initially and uses that value to set the remaining time for the TcpStream timeout. This allows the IDLE loop to reconnect the IDLE connection at the appropriate time. Fixes jonhoo#300.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm connecting to an IMAP server that boots IDLE connections after 30 minutes. I'm using imap-3.0.0-alpha.14, pretty much straight forward
I works well, apart from getting booted periodically.
I believe the issue may be, that the time is not counted from the start of the IDLE loop, but for every read, since the timeout is implemented by calling
TcpStream::set_read_timeout()
once before the loop. So when a response arrives on the client, the timeout is effectively reset.The text was updated successfully, but these errors were encountered: