Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does SSH send 100 packets per keystroke?

eieio.games

Post reply on HN
Print view View original

331–340 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#331

Post by quesera »

ochrist wrote: post #266
quesera wrote: post #195

Earlier quoted context omitted.

> 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.

Mine was 300 baud, probably 1982?

And I felt privileged because the configuration for my TI-99/4A Terminal Emulator (which I believe was called Terminal Emulator) had options for 110 or 300 baud, and I felt lucky to be able to use the "fast" one. :)

My first modem (you always remember your first) had no carrier detection (and no Hayes commands, and no speaker...), so I would dial the number manually, then flip a switch when I heard the remote end pick up and send carrier to get the synchronization started.

It was incredibly exciting at the time.

Re: Why does SSH send 100 packets per keystroke?

#332

Post by dspillett »

tracker1 wrote: post #325
dspillett wrote: post #312

Earlier quoted context omitted.

* 56k baud modems but even my USR (the best of the bunch) never got more than half way to 56k throughput* 56k modem standards were asymmetric, the upload rate being half that of the download. In my experience (UK based, calling UK ISPs) 42kbps was usually what I saw, though 46 or even 48k was stable¹ for a while sometimes. But 42k down was 21k up, so if I was planning to upload anything much I'd set my modem to prete…

Even then, it required specialized hardware on the ISP side to connect above 33.6kbps at all, and almost never reliably so. I remember telling most of my friends just to get/stick with the 33.6k options. Especially considering the overhead a lot of those higher modems took, most of which were "winmodems" that used a fair amount of CPU overhead insstead of an actual COM/Serial port. It was kind of wild.

Yep. Though I found 42k reliable and a useful boost over 36k6 (14%) if I was planning on downloading something big¹. If you had a 56k capable modem and had a less than ideal line, it was important to force it to 36k6 because failure to connect using the enhanced protocol would usually result in fallback all the way to 28k8 (assuming, of course, that your line wasn't too noisy for even 36k6 to be stable).

I always avoided WinModems, in part because I used Linux a lot, and recommended friends/family do the same. “but it was cheaper!” was a regular refrain when one didn't work well, and I pulled out the good ol' “I told you so”.

--------

[1] Big by the standards of the day, not today!

Re: Why does SSH send 100 packets per keystroke?

#333

Post by quesera »

codazoda wrote: post #223
robflynn wrote: post #208

Earlier quoted context omitted.

Ah, the good old days. I remember dialing up local BBSes with QMODEM. AT&C1&D2S36=7DT*70,,,5551212

PoiZoN BBS Sysop chiming in. I ran the BBS on a free phone line I found in my childhood bedroom. I alerted the phone company and a tech spent a day trying to untangle it, but gave up at the end of his shift. He even stopped by to tell me it wouldn’t be fixed. I didn’t know the phone number, so I bought a Caller ID box, hooked it to my home line, and phoned home. It wasn’t long before every BBS in town had a listing f…

That's awesome.

I had to wait til I was old enough to get a phone line in my own name before running a BBS. And also til I had a modem that would auto-answer, which was not a given back then!

But I confess my first question for a working but unassigned phone line would be: who gets the bill for long distance calls?

I had access to no-cost long distance calling through other administrative oversights, but they were a bit more effort to maintain! :)

Re: Why does SSH send 100 packets per keystroke?

#334

Post by GuB-42 »

1980s: 1 packet per keystroke is too much, we must find a solution to bundle them together, for efficiency (see Nagle's algorithm, delayed ACK), also let's send everything in plaintext, including passwords

2020s: ha! with some advanced probabilistic models, we may be able to deduce something about what is being typed behind one of our layers of encryption, let's sent 100 packets per keystroke to mitigate that

Re: Why does SSH send 100 packets per keystroke?

#335

Post by KennyBlanken »

alt187 wrote: post #324
sam_lowry_ wrote: post #273

Earlier quoted context omitted.

Just think of the trees burnt in the name of security!

I can think of a few things that burn more energy per second that I'll burn in my entire lifetime via the use of encryption. Coincidentally, they're all, somehow, insanely useless.

According to my Macbook Pro's energy sensors the predominant user of energy is the screen backlight, most of the time.

Crypto functions are so optimized in hardware that their energy consumption is insignificant...

Re: Why does SSH send 100 packets per keystroke?

#336

Post by KennyBlanken »

swiftcoder wrote: post #11

> 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

The guy in charge of Go's security decreed that SSL 1.3 (which he was a contributor to) was so secure that silly programmers should not be able to override what algorithms are allowed or not allowed, because why would they possibly need to do that, because he's such a genius, and even if someone DID find a security vulnerability, well....they can just wait for Google to publicly disclose it and release a patch, compile the new version, update their code to work with that version of Go, rebuild their containers, put stuff through testing, and then release it into production.

Versus...seeing there's a vulnerability, someone adding a one-line change to disable the vulnerable algorithm, compile, image update, test. And a lot less testing because you're not moving to a new version of the language / compiler.

The man has no practical experience in running a production network service, an ego the size of a small moon, and yet was a major contributor to a security protocol now in use by billions of people.

But hey, you can be a handbag designer and end up head of design at Apple soooooooo

Re: Why does SSH send 100 packets per keystroke?

#337

Post by jacquesm »

geocar wrote: post #302
Rebelgecko wrote: post #179

Earlier quoted context omitted.

Once upon a time I worked on a project where we SSH'd into a satellite for debugging and updates via your standard electronics hobbiest-tier 915mhz radio. Performance was not great but it worked and was cheap.

ELRS?

You can run ELRS on 900 MHz but the bitrate is atrocious.

Re: Why does SSH send 100 packets per keystroke?

#338

Post by Lerc »

tgma wrote: post #318
Lerc wrote: post #295

Earlier quoted context omitted.

That's the judgement made with all consumption of energy. The benefits weighed against the costs. Because of the harms of environmental change, there should be pressure placed to avoid damaging ways to generate that energy. When people complain about the amount of energy being used, they are making the judgement on the benefits. This is subjective and people do not agree on the benefits. The argument you shouldn't do…

Producing cheap energy is something everyone should be able to get behind. There is a solid consensus that it would make a better world. See what I did there? As long as you preach any ideology of yours without talking about its trade-offs you can claim everyone should get behind it. Obviously.

I don't see a problem with that statement.

If you get the situation where the two are in conflict then you have to bring in a judgement, but it makes it explicit what you are prioritising.

Luckily for the case of energy, solar meets both goals.

Re: Why does SSH send 100 packets per keystroke?

#339

Post by peter_d_sherman »

>I am working on a high-performance game that runs over ssh.

By 'ssh', you mean 'ssh' (library/program + protocol + encryption + decryption) on top of TCP/IP, on top of the Internet, right?

OK, I'm not against it... but you do understand that there are all kinds of ways for that to slow things down, right?

Your issues may (or may not!) include such things as:

o Nagle's algorithm AKA buffering AKA packets not being sent until N bytes (where N > 1) ready to send, as other posters have suggested;

o Slower encryption/decryption on older hardware (if users with older hardware is a target market, and if the added loss in speed makes an impact in gameplay, depending on the game, this may or may not be the case...)

o The fact that TCP/IP (as opposed to UDP / Datagrams / "Raw" sockets) imposes a connection-oriented abstraction, requiring additional round trips of ACK ("I got the packet") RESEND ("I didn't get the packet") on top of the connectionless architecture that is the Internet (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...), which adds additonal latency, so, for example if a rural user in Australia experiences a 350ms delay for a raw packet to get to a U.S. server (or vice versa), then TCP/IP might make this 700ms or more, depending on the quality of the connection!

o The speed of the game limited to both the bandwidth and latency of the slowest user (if a multi-player game, and if the game must not update until that user "moves"... again, game architecture will determine this, and it wouldn't be applicable to all games...)

Now, you could use UDP, as other posters have suggested, but then you must manually manage connections and encryption...

That may be the right choice for some types programmers, some types of games/applications -- but equal-and-oppositely it may be the wrong choice for others...

Anyway, wishing you well with your game development!

I haven't used SSH (at least, not in a debug capacity), so I'm not sure what SSH debugging options exist -- but it would be nice if SSH had a full logging debug mode, which would explain exactly WHY it chose to send any given packet that it did along with related helpful information, such as latency/time/other metrics, etc., if it doesn't have this/these feature(s) already...

Post reply on HN