[ih] FTP Design

Bernie Cosell bernie at fantasyfarm.com
Sun Jul 1 07:04:49 PDT 2012


On 1 Jul 2012 at 7:24, Dave Walden wrote:

> I hope Bernie can say how much he was thinking about this before our 
> airplane flight during which he described his idea on cocktail
> napkins.

I can remember a bit, but as with most of that stuff back then it seemed 
more fun and interesting than significant so I didn't pay a lot of 
attention [sigh!].  From my work on the TIP I was already thinking a bit 
about making telnet symmetric.  What I was mostly grapping with was if 
the protocol were symmetric it could "loop" -- if commands passed each 
other over the net, then the responses passed each other, and those 
kicked off other responses, etc.  [one that came to mind (that I recall 
thinking about back then) was with one end saying "I'll send echoes" and 
the other saying "I'll echo locally".  They cross, and each then responds 
"OK you echo".  Each now has gotten a change of state [since each said 
they weren't going to echo and now has been told to] and so each sends 
another "OK I'll send echoes" and "I'll echo locally" and around they 
go....

My actual goal in the sketching on the napkin on the plane flight [and I 
remember mentioning it to Dave, sitting next to me, and waving my hands a 
lot] was "Look: if the commands are will/wont/do/dont and the rules 
follow <THIS> state diagram, then it can't loop and will always end up in 
a reasonable state [just not-looping wasn't enough, of course, lest the 
connection end up with BOTH ends thinking that the other is echoing, or 
vice versa].  Another important idea that it handled was that it was 
extensible: it provided for the notion that one side could ask about 
something unknown and that'd be OK [and the negotiation would do the 
right thing], so there could be fancy-hosts and not-so-fancy ones and 
they could negotiate to make as clever a connection as they could while 
still gracefully handling hosts that could only deal with not-so-clever 
ones.

As I mentioned in a previous thread about this, I really don't recall 
hardly any discussion about this at the meeting [which, I admit, I only 
vaguely recall at all].  I gather that the proposal was just accepted 
[or, perhaps, that Dave did a lot of lobbying/arguing on my behalf that 
I've forgotten..:o)] and my recollection was that attention almost 
immediate turned to designing options.  [one of the first I recall [did 
it ever get implemented?] was RCTE: remote controlled transmission and 
echoing, that was proposed by someone from Hawaii]


>                 Will Crowther                 BBN
> 
> (Crowther was undoubtedly there because of the TIP software effort at that
> time.)

right: At a design review that I still get shudders over, I proposed the 
idea of hacking the IMP, when it moved to the 316 [which had an extra 16K 
of memory], to run "split" -- the upper 16K running as a wholly separate 
system [a proper host system, actually] with the imp part simulating its 
I/O hardware.  The "upper host" could be written as if it were a 
standalone program on a 516 with the IMP [below it] simulating interrupts 
and I/O commands and such.  My recollection is that Frank was very 
dubious that that would work, but I got the go ahead anyway.

Will worked on the original TIP code.  A bit after that, Ralph Alter 
started work on the IBM 2741 [that the right number?] code.  When it all 
kind of worked, they both went to other projects (was that when Will 
started on the Pluribus?) and I inherited it.  The NVT stuff was clearly 
a necessity: in a world of fullduplex, character at a time, ascii 
terminals, we were writing code to make a half-duplex, line-at-a-time 
EBCDIC terminal work.  [and I think that after I hacked on the code 
enough eventually it did: you could actually log into a TENEX system from 
the 2741].  Dave probably remembers: why did we have the mandate to 
support the 2741?

  /Bernie\

-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       






More information about the Internet-history mailing list