Using Ratatui with TCP + Telnet

[jamesmcl113]

Hi, I'm constructing a Telnet server and using ratatui to render the client. To achieve this, I use ratatui to redraw and then diff the terminal buffer with the buffer from the previous redraw to get the changed cells. I then convert these changes into crossterm commands and write the ansi bytes to a buffer which is sent down the TCP stream. This works nicely however I can't set a custom size for the terminal window for each client, it just uses the size from the terminal that I run the server with since I'm using the CrosstermBackend.

Do I need to construct a custom backend to allow me to set the size or is there an easier way to accomplish this?

EDIT:
I've constructed a sort-of mock backend that relies on a CrosstermBackend for most of the trait implementation but using my own sizing for backend.size(). Is this a valid solution or will I run into issues?

[joshka]

Issue number #1000 🎉

I'm constructing a Telnet server and using ratatui to render the client.

Sounds like you're writing something similar to https://github.com/charmbracelet/wish perhaps?

To achieve this, I use ratatui to redraw and then diff the terminal buffer with the buffer from the previous redraw to get the changed cells.

The terminal and backend does most of this diff logic for you already. It will only write the delta of the changes necessary to update its idea of what is currently on the screen. Take a read of Terminal::flush and Buffer::diff.

I'm assuming you're possibly using "Telnet" here generically to mean you're listening on TCP and not that you're fully implementing RFC 854, 1073 etc.

Actual telnet / ssh clients will send resize commands (more info https://unix.stackexchange.com/questions/207782/how-are-terminal-length-and-width-forwarded-over-ssh-and-telnet). It sounds like your app isn't running connected a pseudo-terminal that is allocated for the session, and so you have to handle this sort of thing manually instead of letting the protocol layer handle the interaction with pty sizing. Perhaps there's a part of your architecture choice that's missing there (or a constraint that means this is not relevant?)

I've constructed a sort-of mock backend that relies on a CrosstermBackend for most of the trait implementation but using my own sizing for backend.size(). Is this a valid solution or will I run into issues?

You might be able to skip creating a backend and just use Terminal::with_options(backend, TerminalOptions {viewport: Viewport:Fixed}) for this. Fixed viewports don't respond to autoresize, and you can call Terminal::resize() to update the size when your client size changes. The writer on CrosstermBackend is anything that implements std::io::write, so this might be able to just write directly to your TCP connection somehow - if that fits the way things are setup.

If that doesn't work for you, then I don't see any problem with the approach you mentioned. Wrapping the crossterm backend with another custom backend struct and add your own logic for window size call. All the functional code is implemented on traits, so there likely isn't any problem with private methods that can't be overridden which is nice.

[jamesmcl113]

This is very helpful information, thanks for the extensive reply.

I did notice that Terminal::draw handles diffing the buffers so I know what I'm doing is redunant. I don't think I'll be able to write directly to the stream as it requires async code but I'll look into this. What I would really like is a way to define my own buffer, have Terminal::draw write the changes to this buffer and I can handle the rest. Maybe I could write some kind of custom terminal that would spit out the delta changes as bytes after each draw call?

I'm definitely not fully implementing the Telnet spec atm, but I use some of the protocol for putting the client into the correct mode and I do use RFC 1073 to get the client size. I don't mind doing the resizing manually.

[joshka]

What I would really like is a way to define my own buffer, have Terminal::draw write the changes to this buffer and I can handle the rest

It's possible that the idea in #991 might help your use case somewhat

I'm definitely not fully implementing the Telnet spec atm

I think I'd probably look at doing this behind an SSH connection rather than Telnet for pretty much anything not explicitly noted as being throwaway / PoC code.

[orhun]

There is also Ratatui examples in Russh which makes it possible to serve Ratatui apps over SSH, fwiw: https://github.com/warp-tech/russh/tree/main/russh/examples

[jamesmcl113]

What I would really like is a way to define my own buffer, have Terminal::draw write the changes to this buffer and I can handle the rest

It's possible that the idea in #991 might help your use case somewhat

Yep it looks like #991 is exactly the kind of functionality I'm looking for, hopefully it gets merged soon!

I'm definitely not fully implementing the Telnet spec atm

I think I'd probably look at doing this behind an SSH connection rather than Telnet for pretty much anything not explicitly noted as being throwaway / PoC code.

I chose Telnet since I already knew how to implement some of the spec but I'll take a look at doing it with SSH and the Russh example @orhun linked to.

[joshka]

I built out a simple example of a Pong game using Russh to try it out. It's pretty neat.
https://github.com/joshka/pong-russh/ (PoC quality code - could easily be cleaned up a bit more)