A bit of a strange question here, but I'm wondering if there's any standard way to set the baud rate of non-serial interfaces, e.g. an SSH session to a Linux machine?
There are lots of examples of setting the baud rate for serial ttys in Linux, such as this:
struct termios slow;
tcgetattr(STDOUT_FILENO, &slow);
cfsetispeed(&slow, B1200);
cfsetospeed(&slow, B1200);
tcsetattr(STDOUT_FILENO, TCSANOW, &slow);
However, I've never been able to get any to work for me when working with ttys like an SSH connection. I'm not sure if it's just not supposed to work in those contexts, or if there's something else/different that needs to be done here.
The example compiles and runs just fine, but everything printed out to the screen is still at full speed. I've confirmed none of the functions runs into any issues, tried different baud rates, tried STDIN and STDOUT, set different flags in some of the examples floating around - none of that has any effect.
The stty
command itself also seems to have no effect.
Is it possible to set the baud rate of an SSH session in the first place? Maybe it's not, and that's why it doesn't work.
If not, is there any way to achieve this? Short of a brute force solution like:
for each char in str:
print char
sleep 0.03
In case it wasn't obvious from the question, no, there's not a super useful application of this, but sometimes it's useful to simulate different baud rates without actually using a physical serial connection or anything like that, and it would be useful to handle the connection speed at the terminal layer or in the kernel somehow, rather than doing something dumb like printing everything out character by character. Can this be accomplished?
This must be accomplished entirely server-side (the connected SSH client should not have to do anything special), and the speed must be able to be set on demand just like with cfsetospeed
.
One solution that does work is to use a pseudoterminal, which relays output from the PTY master to the actual file descriptor (e.g. a socket) one character at a time, with usleep
inbetween each call to write
.
However, this results in doing dozens to hundreds of calls to write()
per second, which uses quite a bit of CPU. I doubt there's any way to space out writing a buffer gradually in the kernel, so this kind of system call overhead might be unavoidable, but if there was a more efficient way to do this, that would be great.