| 162 | static void sleep_for_bwlimit(int bytes_written); |
| 163 | |
| 164 | static void check_timeout(BOOL allow_keepalive, int keepalive_flags) |
| 165 | { |
| 166 | time_t t, chk; |
| 167 | |
| 168 | /* On the receiving side, the generator is now the one that decides |
| 169 | * when a timeout has occurred. When it is sifting through a lot of |
| 170 | * files looking for work, it will be sending keep-alive messages to |
| 171 | * the sender, and even though the receiver won't be sending/receiving |
| 172 | * anything (not even keep-alive messages), the successful writes to |
| 173 | * the sender will keep things going. If the receiver is actively |
| 174 | * receiving data, it will ensure that the generator knows that it is |
| 175 | * not idle by sending the generator keep-alive messages (since the |
| 176 | * generator might be blocked trying to send checksums, it needs to |
| 177 | * know that the receiver is active). Thus, as long as one or the |
| 178 | * other is successfully doing work, the generator will not timeout. */ |
| 179 | if (!io_timeout) |
| 180 | return; |
| 181 | |
| 182 | t = time(NULL); |
| 183 | |
| 184 | if (allow_keepalive) { |
| 185 | /* This may put data into iobuf.msg w/o flushing. */ |
| 186 | maybe_send_keepalive(t, keepalive_flags); |
| 187 | } |
| 188 | |
| 189 | if (!last_io_in) |
| 190 | last_io_in = t; |
| 191 | |
| 192 | if (am_receiver) |
| 193 | return; |
| 194 | |
| 195 | chk = MAX(last_io_out, last_io_in); |
| 196 | if (t - chk >= io_timeout) { |
| 197 | if (am_server) |
| 198 | msgs2stderr = 1; |
| 199 | rprintf(FERROR, "[%s] io timeout after %d seconds -- exiting\n", |
| 200 | who_am_i(), (int)(t-chk)); |
| 201 | exit_cleanup(RERR_TIMEOUT); |
| 202 | } |
| 203 | } |
| 204 | |
| 205 | /* It's almost always an error to get an EOF when we're trying to read from the |
| 206 | * network, because the protocol is (for the most part) self-terminating. |
no test coverage detected