[ih] More topology

[Barbara Denny]

 The PE code (some or all?) could also have been written by Holly Nelson, or perhaps James Lieb since he is listed on the technical report besides Jim and Holly.  Holly left SRI shortly before I arrived (When I interviewed at SRI I thought I might end up working with her on my first project there).  I don't remember meeting James Lieb.  BTW, SRI technical reports usually included everyone who worked on an effort so I don't think the PE could have been written by a person not listed on the report.
barbara
    On Tuesday, August 31, 2021, 02:28:12 PM PDT, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:  
 
     > From: Jack Haverty

    > Any host might try to get up to 8 " in-flight" messages. If more than
    > one such host is sending to the same destination, each expecting to be
    > able to keep 8 messages in flight, the IMP would block the PE as it
    > sent the 9th message. 

The person who wrote the PE code (Jim Mathis?) either foresaw the
possibility, or experienced it, as the PE has code to handle exactly this:

  ; IF THE NUMBER OF MESSAGES
  ; OUTSTANDING ON THE CONNECTION IS LESS THAN 8, PUT THE PORT NUMBER
  ; INDICATOR INTO SUB-LINK FIELD OF THE MESSAGE AND OUTPUT THE MESSAGE TO
  ; THE IMP.  IF THE NUMBER OF MESSAGES OUTSTANDING IS GREATER THAN OR EQUAL
  ; TO 8, ENQUEUE THE IORB ONTO THE "BLOCKED" LINKED LIST.  IT WILL BE SENT
  ; WHEN A RFNM IS RECEIVED AND THE OUTSTANDING COUNT IS LESS THAN 8.  THE
  ; HOST PORT WILL BE BLOCKED UNTIL THE MESSAGE IS SENT.

May I suggest that rather than idly speculate about what the PE _might_
have done, people inspect the actual code (sort of - see below), which I
have put online here:

  http://ana-3.lcs.mit.edu/~jnc/tech/gw/pe/

It's not the _original_ PE code, this is the version that I hacked on to turn
it (effectively) into a gateway to the MIT LAN. Still, I didn't chop out lots
of existing functionality, just hung a bag on the side to turn it into a LAN
gateway, so the original PE stuff is all there.

Why didn't we just use the BBN gateway code (which we clearly had access to),
instead of hack the PE? I don't recall for sure, but I suspect our thinking
went something like this: we were already familiar with MOS, and had it (and
had it, the PE and the TIU) building on the local TOPS-20 (and knew it was
clean and easy to work with); but didn't have ELF, or the gateway. It was
probably easier to do the PE hack than get the ELF-based gateway running.


    > From: Steve Crocker

    > Minor point: RFNM = Ready (not Request) for Next Message.

Ironically, the 'improved' ARPANET (post ~'72) actually did kind of act that
way ('Request'). From J.M. McQuillan, W.R. Crowther, B.P. Cosell, D.C. Walden,
and F.E. Heart, "Improvements in the Design and Performance of the ARPA
Network":

  When the message itself arrives at the destination, and the destination IMP
  is about to return the Ready-For-Next-Message (RFNM), the destination IMP
  waits until it has room for an additional multipacket message. It then
  piggybacks a storage allocation on the RFNM. If the source Host is prompt in
  answering the RFNM with its next message, an allocation is ready and the
  message can be transmitted at once.

Easily available not behind one of those irritatig, annoying paywalls, here:

  https://walden-family.com/impcode/1972-improvements-paper.pdf

so you all won't have to find your old hardcopy!

  Noel
-- 
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history