[ih] NCP and TCP implementations

[Bernie Cosell]

On March 10, 2020 14:20:23 Leo Vegoda <leo at vegoda.org> wrote:

> On Tue, Mar 10, 2020 at 11:07 AM Steve Crocker via Internet-history
> <internet-history at elists.isoc.org> wrote:
>>
>> To create the TIP, a second bank of memory was added to the 316 and some
>> interrupts and modes were added to enable switching back and forth between
>> banks.  It was a bit of a kludge with some unexpected interactions.  The
>> BBN crew finally sorted out the details and wrote a delightful titled "It's
>> Amazing That it Works at all."
>
> Am I right in inferring that the key driver behind the design decision
> was cost rather than elegance?

no.  cost wasn't the issue.  in fact elegance was.  I did the design
and most of the code for the tip and the issue was making it
" clean".    the imp was a pretty complicated program {I had
a hand in that, too} and was, at best, squeezed into its 16k.
there really wasn't room in the lower bank for the tip and
it's device buffers, etc.  I thought about how to implement
and it became clear to me that writing a "terminal handling
IMP" was madness.  the underlying IMP code still had to do
everything an imp has to do {routing, forwarding, etc} and
the problem of managing, debugging and updating this 'hybrid"
in parallel, but forked apart from, the main IMP code seemed
like a nightmare.

instead, I cooked up a "virtual host" mechanism and aside
from that mechanism,  the TIP code and its underlying IMP
code were quite insulated from one another.  Imo {ymmv :)}
that split worked out to be pretty elegant and effective.
{as steve hinted} it was a little tricky to get working, but
after that  it was quite solid. the imp was maintained by the
imp guys pretty much independent of the TIP software and
the TIP development/debugging could {and didi} proceed
independently of the IMP software.

/bernie\

                     Bernie Cosell
           bernie at fantasyfarm. com
— Too many people,  too few sheep —