)]}'
{"src/openvpn/oob_client.c":[{"author":{"_account_id":1000041,"name":"ralf_lici","display_name":"Ralf Lici","email":"ralf@mandelbit.com","username":"ralf_lici"},"change_message_id":"fd1d2aae6b87792872761a85ed7d8c7a75d25869","unresolved":true,"context_lines":[{"line_number":271,"context_line":"                  + (rcv.tv_usec - targets[i].sent_at.tv_usec) / 1000;"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"        results[i].responded \u003d true;"},{"line_number":274,"context_line":"        results[i].rtt_ms \u003d (ms \u003e 0) ? (unsigned int)ms : 0;"},{"line_number":275,"context_line":"        results[i].reply \u003d reply;"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"        i \u003d oob_probe_next_target_at(from, targets, results, n, i + 1);"}],"source_content_type":"text/x-csrc","patch_set":19,"id":"34a56652_fc727e56","line":274,"updated":"2026-09-11 15:24:54.000000000","message":"Is it intentional that RTT is always measured from the first probe? `targets[i].sent_at` is not updated when the probe is retransmitted. If this is deliberate, I think it should be stated explicitly.","commit_id":"bbe44ffb969e991f7b5d4b497146621d34eb4111"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"cb9af9cf51e62948daa90095d76498101844d489","unresolved":false,"context_lines":[{"line_number":271,"context_line":"                  + (rcv.tv_usec - targets[i].sent_at.tv_usec) / 1000;"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"        results[i].responded \u003d true;"},{"line_number":274,"context_line":"        results[i].rtt_ms \u003d (ms \u003e 0) ? (unsigned int)ms : 0;"},{"line_number":275,"context_line":"        results[i].reply \u003d reply;"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"        i \u003d oob_probe_next_target_at(from, targets, results, n, i + 1);"}],"source_content_type":"text/x-csrc","patch_set":19,"id":"7c8ef95e_86b86be8","line":274,"in_reply_to":"34a56652_fc727e56","updated":"2026-09-17 07:59:49.000000000","message":"Deliberate: a reply carries nothing that ties it to a send round, so measuring from a resend would make a server that lost the first probe look fast. The comment at the send says so now, and since 1751 the first-send time is kept per address.","commit_id":"bbe44ffb969e991f7b5d4b497146621d34eb4111"},{"author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"change_message_id":"2ad312378f69e3161ad25e73cf90b61c0cf7a3be","unresolved":true,"context_lines":[{"line_number":271,"context_line":"                  + (rcv.tv_usec - targets[i].sent_at.tv_usec) / 1000;"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"        results[i].responded \u003d true;"},{"line_number":274,"context_line":"        results[i].rtt_ms \u003d (ms \u003e 0) ? (unsigned int)ms : 0;"},{"line_number":275,"context_line":"        results[i].reply \u003d reply;"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"        i \u003d oob_probe_next_target_at(from, targets, results, n, i + 1);"}],"source_content_type":"text/x-csrc","patch_set":19,"id":"187af1b5_b3445fac","line":274,"in_reply_to":"7c8ef95e_86b86be8","updated":"2026-09-17 13:18:02.000000000","message":"So that seems like an omission in our spec that we have this problem. We should correct this to not having to resort to something like that.","commit_id":"bbe44ffb969e991f7b5d4b497146621d34eb4111"},{"author":{"_account_id":1000041,"name":"ralf_lici","display_name":"Ralf Lici","email":"ralf@mandelbit.com","username":"ralf_lici"},"change_message_id":"fd1d2aae6b87792872761a85ed7d8c7a75d25869","unresolved":true,"context_lines":[{"line_number":580,"context_line":"            }"},{"line_number":581,"context_line":"            pc.probed[pc.n_probed++] \u003d targets[i].dest;"},{"line_number":582,"context_line":"        }"},{"line_number":583,"context_line":"        openvpn_gettimeofday(\u0026targets[i].sent_at, NULL);"},{"line_number":584,"context_line":"        targets[i].sent \u003d true;"},{"line_number":585,"context_line":"        sent_count++;"},{"line_number":586,"context_line":"    }"}],"source_content_type":"text/x-csrc","patch_set":19,"id":"f0d4268c_5a2baf32","line":583,"updated":"2026-09-11 15:24:54.000000000","message":"The RTT measurement are confounded by the serialized operations that take place between the send phase and the receive phase, because the receive timestamp is taken when `recvfrom` processes the datagram, not when it arrived.\n\nImagine this:\nt\u003d0 ms:   send A\nt\u003d5 ms:   reply from A reaches the socket receive queue\nt\u003d40 ms:  finish sending all other probes\nt\u003d40 ms:  recvfrom reads A\u0027s already queued reply\n\nThe code records approximately 40 ms for A, even though its network RTT was approximately 5 ms.\n\nMaybe this is not a problem with a small number of remotes but it might be noticeable with a larger one.\n\nThere is also a related duplicate-endpoint problem here: if 2 entries share 1 endpoint, only 1 datagram is sent, but each entry gets a separate `sent_at` recorded as the loop reaches it. Both are then credited from the same reply but may receive slightly different RTTs.","commit_id":"bbe44ffb969e991f7b5d4b497146621d34eb4111"},{"author":{"_account_id":1000008,"name":"stipa","display_name":"Lev Stipakov","email":"lstipakov@gmail.com","username":"stipa"},"change_message_id":"cb9af9cf51e62948daa90095d76498101844d489","unresolved":false,"context_lines":[{"line_number":580,"context_line":"            }"},{"line_number":581,"context_line":"            pc.probed[pc.n_probed++] \u003d targets[i].dest;"},{"line_number":582,"context_line":"        }"},{"line_number":583,"context_line":"        openvpn_gettimeofday(\u0026targets[i].sent_at, NULL);"},{"line_number":584,"context_line":"        targets[i].sent \u003d true;"},{"line_number":585,"context_line":"        sent_count++;"},{"line_number":586,"context_line":"    }"}],"source_content_type":"text/x-csrc","patch_set":19,"id":"e3b356c4_6521d091","line":583,"in_reply_to":"f0d4268c_5a2baf32","updated":"2026-09-17 07:59:49.000000000","message":"The send phase is only sendto() calls — resolution happens before it — so the gap between the first send and the first recvfrom is microseconds per address, not tens of milliseconds; the comment at the receive notes that queue time is included. Kernel receive timestamps (SO_TIMESTAMP) would remove even that, but there is no portable equivalent on Windows, so I left it. The duplicate-endpoint part is fixed: the address is sent once and every entry sharing it gets that one send time.","commit_id":"bbe44ffb969e991f7b5d4b497146621d34eb4111"}]}