[Bug]: Opened client connection not receive data after some time.

[lemunozm]

What happened?

Hi!

I have a server that opens a client connection. It seems like after a few minutes o so, no more data comes to that socket. The socket is still open, but no data is received. Is this intentional? My gut says that some port/NAT/docker layer is closing the port mapping for this client connection.

Thanks for your effort in this project!

Version

v0.17.0 (the crate is v0.19.0)

Which operating system(s) are you seeing the problem on?

In deployment

Which CPU architectures are you seeing the problem on?

In deployment

Relevant log output

No response

Duplicate declaration

• [X] I have searched the issues and there are none like this.

[jonaro00]

Have you made sure it is not the project idling? https://docs.shuttle.rs/introduction/idle-projects

Also, make sure the versions of cargo-shuttle and the dependencies are 0.19.x

[lemunozm]

Thanks for the answer!

I've tested with --idle-minutes 0 that disables the timeout, and updated to 0.19.x, but I still have the issue.

Note that if running locally with cargo shuttle run it works, and I can receive input data in the socket at any moment.

[jonaro00]

Which sort of socket logic are you using? Is it a websocket with one of the supported frameworks?

Some more context and steps to reproduce the bug would be helpful.

[lemunozm]

Sure!

What I'm doing is opening a IMAP connection over a TLS/TCP connection with a gmail server. Once opened, I start idling from this, which is a special way of handling the IMAP connection to keep listening to the server instead of polling the server continuously with requests.

Gmail notifying correctly during 2-3 minutes to my shuttle application, later not. Nevertheless, each 30 minutes I run again the idle over the same opened connection, and I get an answer again from the server, again during 2-3 minutes only. From this I extract that the server is not closing the connection with me. And it is notifying my shuttle application, but I'm not receiving the messages.

[jonaro00]

Alright.

My first suspicion is the TCP stream timing out. The deployed app sits in a cloud environment with different networking setup than your local run.

To test this, we could make a websocket server (Shuttle servers will only receive incoming HTTP behind a reverse proxy) and client in two separate projects. The client connects, and the server sends a message in a loop with an increasing amount of time between each message, until something breaks. This can be done locally and deployed to verify.

Do you think this could be a reasonable test?

[lemunozm]

Actually, I think it's a great test! I'll try to get some time to do it soon 👍🏻

[jonaro00]

For context, from googling about it: https://stackoverflow.com/a/45694328