My original comment about using rudimentary character-at-a-time protocols to communicate between machines was intended to refer to the original "C" command in the IMPs' debugger which allowed one to "Crosspatch" to another specified host or pseudo-host. There was a pseudo host machine which ran the control TTY on each IMP. By crosspatching to that pseudo-host, one was able to type characters on one machine's TTY bundled into a one-character packet and print on the remote machine's TTY. Similarly, characters typed on the remote machine's TTY were built into one-character packets and sent to your TTY where they would print. The only protocols to prevent interspersing characters in the two directions were the human protocols such as those discussed on this thread.
A number of us used this mechanism in software on host machines. These packages would take the characters coming in from a remote host or pseudo-host and put them into what on the PDP-10 was called a Pseudo Teletype, or PTY, where the OS would deal with them just as if they were typed on an actual TTY connected to the host machine. Characters coming back over the PTY were bundled into packets and sent back to the host or pseudo-host that had sent in the packets.
Never worried about trivia such as flow control and error control; when typing on a 110 bit per second TTY and sending it down an almost-empty 50 kb circuit, congestion wasn't much of a concern. And the design philosophy behind the IMPs at the time was that the network was "as reliable as the accumulator" -- you didn't write your software to worry about what happened if the accumulator dropped bits, nor to worry about what happened if the network dropped bits. I didn't worry about what would happen if more than one user were to try to use this rudimentary kludge at the same time.