Review missing timeouts

[josecelano]

I've opened this issue to collect and track all past, current and future problems related to timeouts.

Recently we have had problems with the live demo because the http_health_check binary does not have a timeout. Healthchecks started by the docker daemon are waiting forever if they don't receive a response, consuming more and more resources until the container crashes.

There are more places where we could have such problems. I'm going to describe here some places potentially affected by this type of issue.

Potentially affected code

Healthcheck binary

It's used in the tracker but also in the Index.

It's currently being fixed:

• Fix zombie healtcheck threads #597
• Add timeout to the http_health_check.rs binary #604

Tracker API

It uses Axum. All services using Axum have the same problem. For more info see the issue opened in the Index. It applies the same here.

• Tracker API: Add a timeout to the TLS handshake, waiting for headers, and waiting for receiving headers #612

HTTP Tracker

It also uses Axum.

• HTTP Tracker: Add a timeout to the TLS handshake, waiting for headers, and waiting for receiving headers #613

UDP Tracker

We do not use any framework. We handle requests directly with a loop.

• We don't have timeouts.

• If I'm not wrong all requests are executed sequentially. We don't use threads. If one request takes forever for some reason the server can not handle more requests and there is no timeout.

• Add timeout to UDP tracker request processing #609

@da2ce7 is working on some improvements like:

• Create a worker that can handle 50 requests at the most.
• It spawns a new thread for each request.
• It implements a graceful shutdown waiting for the active requests to finish when the application receives a halt signal.

I think he has not added yet the timeout feature.

By the way @WarmBeer since you are working on performance issues:

• Use dashmap for torrent in memory storage instead of the std hashmap #565
• Benchmark Tracker.update_torrent_with_peer_and_get_stats performance using Criterion #496

I wonder if improving the repository can improve the UDP tracker since requests are handled sequentially anyway or am I missing something @WarmBeer?

Tracker Checker

• Tracker Checker: handle UDP Tracker timeouts #682
• Tracker Checker: handle Health Check timeouts #678
• Tracker Checker: handle HTTP Tracker timeouts #679
• Tracker Checker: gracefully handle timeouts #677

Conclusion

There might be other cases.

Relates to:

• Denial of Service attack factor #324

[mickvandijke]

I wonder if improving the repository can improve the UDP tracker since requests are handled sequentially anyway or am I missing something @WarmBeer?

Yeah the performance improvements I'm working on only improve parallel access to the torrent repository. Sequential access should be the same.

#565