XX-net/XX-Net · warning

mark_sn_timeout sn:%d t:%f

Error message

mark_sn_timeout sn:%d t:%f

What it means

Logged in mark_sn_timeout when a sequence number is first added to the timeout list. It records that a data chunk sent to the server has not been acknowledged, along with how long ago it was sent (server_time - t). This is a routine retransmission-tracking warning, not a failure by itself.

Source

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

                # xlog.debug("recv_pool put sn:%d in order", sn)
                self.process_callback(data)
                self.next_sn += 1

                while self.next_sn in self.block_list:
                    # 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"],

View on GitHub (pinned to cfa5bc17b6)

Solutions

  1. Check network quality/latency to the tunnel server
  2. Inspect retransmit rate; tune timeout values
  3. If persistent, verify server-side ACK generation is healthy
Defensive patterns

Strategy: retry

Prevention

When it happens

Trigger: process_server_unacked_sent_sn reports SNs the server has not ACKed; the first time an SN is seen it is added to timeout_sn_list and this warning fires with the elapsed time since send.

Common situations: Normal under packet loss or slow links; if it fires constantly, the uplink is lossy or the server is slow to ACK.

Understand the failure class

Related errors


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