[TUHS] ECU

I had an ECU connecting the BRL-GATEWAY to the Imp in another building. Rutgers also used an ECU to get their internet connection of the Columbia IMP. When visiting BBN’s NOC I noted little red squares on the network map for my site. I was told these signified an ECU and it is because it causes problems when the host crashes. Let me explain this quaint piece of operation. Both the IMP and the LH or DH host interface have a relay that indicates the interface is powered up. The idea is that if you shutdown the machine (or the imp) the relay fails open. That’s fine for a gross shutdown, but let’s say the machine just hangs. The IMP has a feature called “TARDY DOWN.” If you stop accepting packets for a while, the thing declares you “TARDY DOWN” (effectively down for the rest of the net). This is signified on the later C-30 imps by the display register bit for that host flashing. Now the IMP says, “Hey, let me try to wake this guy up.” It does this by dropping its relay for a second hoping to trick the host into thinking it has rebooted and it should reinitialize. Of course, this gambit rarely works, but if the host did wake up, if it starts processing messages again, the IMP says “All is well” and declares the host up. Now, what if you had an ECU. Well, when the IMP flaps it’s relay, the ECU says “Hey, something happened to the IMP.” I better reset everything including any buffered packets. The ECU actually buffers three packets or so while it is transferring them to the other end. Well, now that the buffer is empty, it can take three more packets. The IMP declares it up. Of course, the host isn’t really there, so the packets just stay there and then the ECU fills up and stops answering the IMP and the IMP eventually declares it TARDY DOWN again. Lather, Rinse, Repeat. This wouldn’t be so bad except that every time there’s a transition a message is printed out in the NOC. So a dead host on an ECU causes a couple of messages to be printed every three minutes until someone does something about it. Later, we had similar fun and games with the EGP protocol. The protocol suggest you not declare the peer up until after you receive n (where n = 3) hello messages. I’m more optimistic than that. My implementation sent a “OK, You’re up” response after a single HELLO. Of course, this pissed off some other client who said, I can’t be up after only one HELLO, I better start the whole thing over again. Lather, Rinse, Repeat.