XX-net/XX-Net · warning

mark_sn_timeout renew sn:%d t:%f

Error message

mark_sn_timeout renew sn:%d t:%f

What it means

Logged when an SN already in the timeout list is re-marked with a newer server send time, renewing its timeout window. Means the same unacknowledged SN was resent/reported with a fresher timestamp.

Source

Thrown at code/default/x_tunnel/local/base_container.py:342

                    # xlog.debug("recv_pool sn:%d processed", sn)
                    self.block_list.remove(self.next_sn)
                    self.next_sn += 1
                return True
        except Exception as e:
            raise Exception("recv_pool put sn:%d len:%d error:%r" % (sn, len(data), e))
        finally:
            self.lock.release()

    def mark_sn_timeout(self, sn, t, server_time):
        # xlog.warn("mark_sn_timeout down_sn:%d", sn)
        with self.lock:
            if sn not in self.timeout_sn_list:
                self.logger.warn("mark_sn_timeout sn:%d t:%f", sn, server_time - t)
                self.timeout_sn_list[sn] = {
                    "server_send_time": t,
                }
            elif t > self.timeout_sn_list[sn]["server_send_time"]:
                self.logger.warn("mark_sn_timeout renew sn:%d t:%f", sn, server_time - t)
                self.timeout_sn_list[sn]["server_send_time"] = t

    def get_timeout_list(self, server_time, timeout):
        sn_list = []
        with self.lock:
            for sn, info in self.timeout_sn_list.items():
                if server_time - info["server_send_time"] < timeout:
                    continue

                if server_time - info.get("retry_time", server_time) < timeout:
                    continue

                self.logger.warn("get_timeout_list sn:%d sent:%f retry:%f", sn, server_time - info["server_send_time"],
                                 server_time - info.get("retry_time", server_time))
                info["retry_time"] = server_time
                sn_list.append(sn)

        return sn_list

View on GitHub (pinned to cfa5bc17b6)

Solutions

1. Monitor frequency; occasional renewal is normal
2. Reduce link congestion or switch front/server if continuous
3. Verify clock synchronization between peers affecting server_time

When it happens

Trigger: Server reports an SN unacked again after a retry, with a newer send time than the stored one.

Common situations: High loss links where the same chunk is resent multiple times; expected behavior of the renewal logic.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• mark_sn_timeout sn:%d t:%f
• get_timeout_list sn:%d sent:%f retry:%f
• roundtrip failed, no:%d target:%d on_road:%d timeout:%d send
• update_quota_loop timeout fail.
• time out

AI-assisted analysis of XX-net/XX-Net@cfa5bc17b6 (2026-08-27). Data as JSON: /api/errors/cd3459ac5ae2375b. Report an issue: GitHub.