The ssh client on your local end receives SIGINT and processes it by sending a special kind of packet over the ssh session to the other side; the sshd on the remote side receives this special packet and processes it by sending SIGINT to whatever command it has originally spawned.
IIRC telnet instead uses urgent TCP packets to indicate SIGINT.
My guess:
The ssh client on your local end receives a 0x03 byte directly from the terminal, because it has disabled ICANON and ISIG and whatnot, and forwards it to the remote connection. The remote sshd then feeds the 0x03 byte to the pseudoterminal it has setup, and then the (remote) kernel may or may not interpret that as SIGINT. For example, ISIG could be disabled (“stty -isig”) or it might be a different key (e.g. “stty intr '^X'”, as mentioned elsewhere in this thread).
Your setup fails to distinguish keyboard interrupts (intended for the remote machine) and real SIGINTs generated by kill(1). It also uses the local termios(4) settings instead of the remote ones.
You may actually be right; I know that SSH channel protocol has special message kind specifically for sending signals to the remote process, which is different from channel messages with normal data, but I don't know if it's used by actual ssh client implementations. They may simply just put local tty in raw mode and forward all input from it as normal data.
Hard to say without looking at the actual code, and right now I am not particularly in a mood for reading C sources at the moment. Maybe someone else is and will tell us the true story!
P.S. Now that I think of it, ssh implementations have to "sync" local and remote tty parameters or at least make it look sane for the user: if you resize your local xterm, arguably the remote e.g. vi should get notified, but what if it's the remote process that changes the terminal dimensions, should your local xterm get resized as a result?
> P.S. Now that I think of it, ssh implementations have to "sync" local and remote tty parameters or at least make it look sane for the user
Hadn’t thought about this before, but I think only window size needs to be synced (maybe baud rate and parity? I really have no idea how those would work)
> if you resize your local xterm, arguably the remote e.g. vi should get notified, but what if it's the remote process that changes the terminal dimensions, should your local xterm get resized as a result?
Huh, TIL processes other than the pty master (the terminal emulator usually) can change window size. Glad I checked my sources before writing off a comment …
I think I'm missing something. Does readability have a special meaning in this context or is it really as basic as it sounds, and therefore all the more ridiculous for being such a bottleneck?
I am the maintainer of FluffOS, (www.fluffos.info), a mud game engine.
MUD is my entry point to programming and I thought I can continue work on making MudOS better.
If anyone would like to get in touch, please join Gitter.im/fluffos
bundling with (unholy-ly immature) SDN is the most damning things for its adoption. It is thought to be needed for "live migration", but I don't see me needing that anytime soon because we run on virtual machines anyway?
Iaas provider is not going away,paying for the cost of SDN now for features that doesn't even exists yet, is insane.
SDN isn't required for k8s, what is required is that each Pod (group of containers) get it's own IP address, and that the IP address is routeable in the cluster. In many cases, the easiest way to achieve this is via an SDN, but it is also achievable by programming traditional routers.
The reason for wanting an IP address per pod is that it eliminates the need for port mangling, which dramatically simplifies wiring applications together.
the problem with port mangling is that your application starts running on random ports, so in addition to requiring discovery for IP addresses, you now also have to do discovery for ports, which pretty much requires custom code and infrastructure linked into your binaries (how do you convince nginx/redis/... to use your lookup service for ports?)
And ports are different between different replicas of your service, since they're chosen at random during scheduling.
It also makes ACLs and QoS harder to define for the network, since you don't have a clean network identity (e.g IP Address) for each application.
