xBBN
  • Home
  • Honors
  • Timelines
    • BBN Internet Engineering Timeline
    • History of the Internet
    • Current BBN Timeline
  • Publications
    • Books >
      • A Culture of Innovation
      • Sound Ideas
      • Riding the Waves: A Life in Sound, Science, and Industry
      • Tulips to Thresholds
    • Papers & Articles >
      • The @ Sign Nobel
      • BBN and Internet History
      • Ray Tomlinson receives Webby
      • Citations and Notes on the Development of EMail
    • Websites >
      • www.bbn.com
  • Photographs
  • Memorials
    • Richard Bolt
  • Interests
    • History of the BBN Piano
    • Adventure: Here's where it all began...
  • Humor
    • Boy Boy Nancy
    • Sturdleigh Press International
    • The BeanCo Chronicles

Note 31

FROM:  Ben Barker

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.

/Ben    10/22/2011

Copyright 2012-2022 @ xbbn.org under a Creative Commons license.
Picture