High bandwidth usage (~200KB/s) and TUI flickering compared to mosh (~7KB/s)

[DarcySail]

Hi, thank you for developing this excellent tool! I'm using it as a mosh replacement.
I've encountered a strange issue when running Gemini CLI inside a tssh session:

The TUI keeps flickering constantly

Data transfer rate reaches approximately 200KB/s to my local laptop
My tssh client and server have limited bandwidth, so 200KB/s causes severe lag, which made me notice this problem

Comparison with mosh:

When using the same scenario with mosh, this issue does not occur:
No flickering
Data transfer stays at a reasonable ~7KB/s instead of 200KB/s
This suggests tssh may be handling terminal updates differently than mosh, resulting in significantly higher bandwidth consumption.

Environment:

Client bandwidth: Limited/low
Tool: Gemini CLI (TUI application)
Issue: High data transfer + screen flickering

[lonnywong]

Hi @DarcySail, thanks for reporting this issue!

To help me investigate, could you please confirm:

1. Which version of tsshd are you using? Is it v0.1.6 or an earlier version? (In tsshd v0.1.6, I optimized the QUIC packet frequency - by default, it now sends about 3 UDP packets per second in QUIC mode)

2. Which protocol are you using? QUIC or KCP? (Note: KCP protocol prioritizes low latency but may consume more bandwidth compared to QUIC)

Regarding the keep-alive mechanism: tssh and tsshd are designed to detect connection status every second by default, which helps achieve faster recovery (around 3 seconds) when switching networks. This is different from mosh's default behavior. If you want to reduce the frequency, you need to adjust both UdpHeartbeatTimeout and UdpReconnectTimeout configurations together.

For reference, you might want to check this related issue: trzsz/tsshd#13

Looking forward to your feedback on the version and protocol details.

[lonnywong]

Regarding the screen flickering issue, it might be caused by insufficient bandwidth triggering reconnections every 3 seconds. Each reconnection will refresh the screen, which could result in the flickering effect.

Please make sure you're using tsshd v0.1.6 or later, and try increasing both UdpHeartbeatTimeout and UdpReconnectTimeout configurations to see if it helps. You can also add the --debug option when logging in (e.g., tssh --debug xxx), and check the logs to see if reconnections are being triggered repeatedly.

[DarcySail]

@lonnywong
Thanks for your patient reply.

• tsshd --version
  trzsz sshd 0.1.6
• UdpMode KCP

As for timeout configuration, here is:
#!! UdpHeartbeatTimeout 15
#!! UdpReconnectTimeout 604800

I'll add --debug to see any further information.

[lonnywong]

Given the limited bandwidth, I recommend using QUIC instead:

UdpMode QUIC

[DarcySail]

Using the script output.raw command to capture screen output, I found that the output file sizes for mosh + gemini cli, tssh + gemini cli, and ssh + gemini cli are roughly on the same order (about 300–500 KB for ~5 s), with the mosh experiments sometimes producing even larger files.

Both tssh and ssh consume around 100 KB/s of bandwidth, whereas mosh uses only about 5 KB/s.

Inspecting the contents of the output.raw file, I discovered that gemini cli’s TUI implementation is very inefficient: it redraws and refreshes the entire screen. The correct approach would be character-level refreshing.

Anyway, I noticed that running gemini cli under tssh maxed out my bandwidth, while under mosh the bandwidth was nearly zero, yet the display effect was the same (at least I couldn’t see any difference with the naked eye).

Searching around, I learned that in principle mosh adopts an incremental update approach, using a protocol called the State Synchronization Protocol (SSP), whereas ssh and tssh both use full updates.

You can easily reproduce the difference between mosh and tssh using the following full-draw script:

import sys
import time
import shutil

# --- ANSI Control Constants ---
ESC = "\033"
HIDE_CURSOR = f"{ESC}[?25l"   # Hide cursor
SHOW_CURSOR = f"{ESC}[?25h"   # Show cursor
MOVE_TO_HOME = f"{ESC}[H"     # Move cursor to top-left (0,0)
RESET_COLOR = f"{ESC}[0m"     # Reset color attributes
GREEN_BG = f"{ESC}[42;30m"    # Green background, black text

def main():
    # Hide the cursor to prevent annoying flickering during redraws
    print(HIDE_CURSOR, end="", flush=True)

    counter = 0

    try:
        while True:
            # 1. Get current terminal size (e.g., 80x24)
            # We fetch this every frame so the TUI adapts if you resize the window
            cols, rows = shutil.get_terminal_size()

            # --- 2. Build the full frame in memory (Render Buffer) ---
            # We use a list to store the string for each line
            buffer = []

            # Top border
            buffer.append("=" * cols)

            # Prepare content strings
            title = " FULL SCREEN REDRAW MODE "
            status = f" Frame: {counter} | Resolution: {cols}x{rows} "

            # Generate content for the middle rows
            # We must manually calculate every line and fill empty areas with spaces.
            # This ensures we "overwrite" the old pixels from the previous frame.
            for y in range(1, rows - 1):
                line_content = ""

                # Example: Display dynamic content at specific vertical positions
                if y == 2:
                    line_content = title.center(cols)
                elif y == rows // 2:
                    # The counter in the middle
                    txt = f" COUNTER: {counter:05d} "

                    # Calculate padding to center the text
                    # We handle padding manually to wrap the text in color codes
                    padding_len = (cols - len(txt)) // 2
                    prefix = " " * padding_len
                    suffix = " " * (cols - len(txt) - padding_len)

                    # Construct the line: Padding + Color Start + Text + Reset Color + Padding
                    line_content = prefix + GREEN_BG + txt + RESET_COLOR + suffix

                elif y == rows - 3:
                    line_content = status.center(cols)
                else:
                    # Blank line: MUST fill with spaces!
                    # If we don't print spaces here, residue from the previous frame remains.
                    line_content = " " * cols

                # Simple truncation to prevent overflow (prevents accidental wrapping)
                # Note: This is a simplified check; stripping ANSI codes for length calc is better in prod.
                if len(line_content) > cols + 20:
                     line_content = line_content[:cols]

                buffer.append(line_content)

            # Bottom border (Last line)
            # We often make the last line 1 char shorter to prevent the terminal from scrolling down
            buffer.append("=" * (cols - 1))

            # --- 3. Core Logic: Output all at once (Swap Buffer) ---
            # Join all lines into one massive string, prefixed with the "Move to Home" command.
            # We NEVER send a "Clear Screen" command. We just overwrite everything.
            full_frame = MOVE_TO_HOME + "\n".join(buffer)

            # Write to stdout using low-level calls for performance
            sys.stdout.write(full_frame)
            sys.stdout.flush()

            # Update counter
            counter += 1

            # Control Frame Rate (FPS)
            time.sleep(0.05) # Approx 20 FPS

    except KeyboardInterrupt:
        # Exit handling: Restore cursor and reset colors
        print(RESET_COLOR + SHOW_CURSOR)
        print("\nExited.")

if __name__ == "__main__":
    main()

[DarcySail]

https://mosh.org/mosh-paper-draft.pdf
mobile-shell/mosh#1087
Are the tssh developers interested in implementing this feature? It’s a lifesaver on unstable networks.

[lonnywong]

The State Synchronization Protocol (SSP) has several known issues:

• mosh prevents the use of scrollback mobile-shell/mosh#122
• mosh does not transmit OSC 52 sequence to client mobile-shell/mosh#637
• Screen corruption with neovim mobile-shell/mosh#1041
• [Bug] Visual selection of a wrapped line in Vim shows incorrect characters mobile-shell/mosh#1295
• Mosh, tmux, nvim rendering/redrawing issues mobile-shell/mosh#1281

There are currently no plans to support it. If time permits in the future, it may be considered as an optional feature.