mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2025-01-24 14:33:16 +00:00
f27b5ea8dc
By default, when data is sent over a socket, both the write timeout and the read timeout for that socket are refreshed, because we consider that there is activity on that socket, and we have no other means of guessing if we should receive data or not. While this default behaviour is desirable for almost all applications, there exists a situation where it is desirable to disable it, and only refresh the read timeout if there are incoming data. This happens on sessions with large timeouts and low amounts of exchanged data such as telnet session. If the server suddenly disappears, the output data accumulates in the system's socket buffers, both timeouts are correctly refreshed, and there is no way to know the server does not receive them, so we don't timeout. However, when the underlying protocol always echoes sent data, it would be enough by itself to detect the issue using the read timeout. Note that this problem does not happen with more verbose protocols because data won't accumulate long in the socket buffers. When this option is set on the frontend, it will disable read timeout updates on data sent to the client. There probably is little use of this case. When the option is set on the backend, it will disable read timeout updates on data sent to the server. Doing so will typically break large HTTP posts from slow lines, so use it with caution. |
||
|---|---|---|
| .. | ||
| design-thoughts | ||
| internals | ||
| acl.fig | ||
| architecture.txt | ||
| configuration.txt | ||
| gpl.txt | ||
| haproxy-en.txt | ||
| haproxy-fr.txt | ||
| haproxy.1 | ||
| lgpl.txt | ||
| queuing.fig | ||