I've got a C++ server application which provides a listening TCP port for support personnel to connect to. They can issue commands and get responses. It's working fine from the application perspective.
My problem arises when they use telnet(1) to connect, and if they (for some reason) type a ^C. My server sees the parsed control characters that telnet sends me, and I can ignore or process them as I see fit. But the telnet client itself goes into some state where it stops outputting my server's responses to the client's screen.
I know I could either 1) tell them not to use telnet or 2) tell them to do a toggle autoflush inside the telnet app, or via ~/.telnetrc or whatever. But what I would prefer to do, if possible, is respond in the server with the correct protocol sequence to get their client to do the right thing with the text that follows. This just feels like it'd be a better UX for them. Their job sucks enough as it is.
Is this possible? I've been through the RFC and it's not clear. From my own past use of telnet in the past, this feels like it's doable, but my memory may be fuzzy.
The idea behind IAC DO TIMING-MARK (FF FD 06) is to suppress the output of the process that is to be interrupted by the IAC IP interrupt process (FF F4) command. In this way the telnet client program hides all output from the user until it receives a proper timing mark or notification that timing mark is not supported by the server.
You may or may not respond or take action to the IAC IP but you have to respond to IAC DO TIMING-MARK. The easiest way in your case is to respond that you ignored it by IAC WONT TIMING-MARK (FF FC 06) and the client should continue displaying all the output normally.
If you really terminate the current job, then you should flush your buffers and then respond with IAC WILL TIMING-MARK, which means that the client will discard all server's output from the moment the user pushed ^C to the place in the stream where it finds the IAC WILL TIMING-MARK (FF FB 06).