> I am working on a high-performance game that runs over ssh. WAT. Please no.
Why not? If it's high-performance, it's fine.
If you spend entire CPU to process few megabits of SSH traffic, it isn't high performance
Why does SSH send 100 packets per keystroke?
261–270 of 375 posts
Re: Why does SSH send 100 packets per keystroke?
#262Earlier quoted context omitted.
Fellow old here, I had several 56k baud modems but even my USR (the best of the bunch) never got more than half way to 56k throughput. Took forever to download shit over BBS...
The real analog copper lines were kind of limited to approx 28K - more or less the nyquist limit. However, the lines at the time were increasingly replaced with digital 64Kbit lines that sampled the analog tone. So, the 56k standard aligned itself to the actual sample times, and that allowed it to reach a 56k bps rate (some time/error tolerance still eats away at your bandwidth) If you never got more than 24-28k, you…
56k was also unidirectional, you had to have special hardware on the other side to send at 56k downstream. The upstream was 33.6kbps I think, and that was in ideal conditions.
Re: Why does SSH send 100 packets per keystroke?
#263Just replace it with zeromq with curvemq.
I could vibecode an SSH zmq daemon in an afternoon.
Re: Why does SSH send 100 packets per keystroke?
#264How do the HPN patches compare?
Re: Why does SSH send 100 packets per keystroke?
#265No TLDR. -.-
Re: Why does SSH send 100 packets per keystroke?
#266Earlier quoted context omitted.
"where we might as well save the bandwidth" I come from a world (yesteryear) where a computer had 1KB of RAM (ZX80). I've used links with modems rocking 1200 bps (1200 bits per second). I recall US Robotics modems getting to speeds of 56K - well that was mostly a fib worse than MS doing QA these days. Ooh I could chat with some bloke from Novell on Compuserve. In 1994ish I was asked to look into this fancy new world…
> I've used links with modems rocking 1200 bps Yo, 300 baud, checking in. Do I hear 110? +++ATH0
My first modem (from 1987) was 300 baud, but it could be used in a split mode called 75/1200.
Before that I used 50 baud systems in the military as well as civil telex systems.
Re: Why does SSH send 100 packets per keystroke?
#267> Obviously forking go’s crypto library is a little scary, and I’m gonna have to do some thinking about how to maintain my little patch in a safe way This should really be upstreamed as an option on the ssh library. Its good to default to sending chaff in untrusted environments, but there are plenty of places where we might as well save the bandwidth
It's not just the pointless chaff, the SSH protocol is inherently very chatty, and SFTP even more so. The solution, for a high-performance game, is don't use SSH. Either run it over Wireguard or grab some standard crypto library and encrypt the packets yourself. You'll probably make a few minor mistakes but unless the other player is the NSA it'll be good enough.
For that matter, why does it need to be encrypted at all? What's the threat model?
If there really is a genuine need to encrypt and low latency is critical, consider using a stream cipher mode like AES-CTR to pregenerate keystream at times when the CPU is lightly loaded. Then when you need to encrypt (say) 128 bytes you peel off that many bytes of keystream and encrypt at close to zero cost. Just remember to also MAC the encrypted data, since AES-CTR provides zero integrity protection.
Re: Why does SSH send 100 packets per keystroke?
#268Wait, go back to the first sentence:
> I am working on a high-performance game that runs over ssh. The TUI for the game is created in bubbletea 1 and sent over ssh via wish.
> The game is played in an 80x60 window that I update 10 times a second. I’m targeting at least 2,000 concurrent players, which means updating ~100 million cells a second. I care about performance.
High performance with ssh and wish? For sure not. Rather use UDP over secure sockets. Or just normal sockets. Even Claude would come up with much faster code than the ssh/wish nonsense. Or mosh, but this also too complicated.
Re: Why does SSH send 100 packets per keystroke?
#269Wait, go back to the first sentence: > I am working on a high-performance game that runs over ssh. The TUI for the game is created in bubbletea 1 and sent over ssh via wish. > The game is played in an 80x60 window that I update 10 times a second. I’m targeting at least 2,000 concurrent players, which means updating ~100 million cells a second. I care about performance. High performance with ssh and wish? For sure not…
The author wanted people to be able to just "ssh mygame", no? In that sense, ssh was a design requirement.
Re: Why does SSH send 100 packets per keystroke?
#270Earlier quoted context omitted.
The real analog copper lines were kind of limited to approx 28K - more or less the nyquist limit. However, the lines at the time were increasingly replaced with digital 64Kbit lines that sampled the analog tone. So, the 56k standard aligned itself to the actual sample times, and that allowed it to reach a 56k bps rate (some time/error tolerance still eats away at your bandwidth) If you never got more than 24-28k, you…
Yeah 28k sounds more closer to what I got when things were going well. I also forget if they were tracking in lower case 'k' (x1000) or upper case 'K' (x1024) units/s which obviously has an effect as well.
Line speed is always base 10. I think everything except RAM (memory, caches etc.) is base 10 really.