[HECnet] Old protocols in new ones

If that were done by the other implementations things would indeed be ok. The routing spec lists the requirements: The required Data Link Layer guarantees for point-to-point links are: 1. Provision that both source and destination nodes complete start-up before message exchange can occur 2. Detection of remote start-up 3. Provision that no old messages be received after start-up is complete 4. Masking of transient errors in order to prevent packet data corruption 5. Provision for not duplicating or corrupting packets 6. Packet sequentiality ensuring that, if a packet has been received, all previously sent packets have been received 7. Reporting of failures and degraded circuit conditions "just inform DECnet that the link went down" is a good summary of requirements 1, 2, and 3. But, as far as I can tell from observation, Multinet on VMS does not do this. Instead, there is no link between the TCP connection state and the routing layer protocol machinery. It's strange that this is so, given that DDCMP does implement these things correctly (of course) which means the interfaces must exist in DECnet. One wonders why the Multinet people did not make those calls. Perhaps they didn't know of them; perhaps they didn't care enough to bother. Given that they created Multinet over UDP my assumption is that they didn't care enough -- the existence of Multinet over UDP is proof positive that they didn't know what they were doing and never bothered to read and understand the DECnet routing protocol specification. Yes, that's one way to describe the observed misbehavior. It may be that it's an explicit asymmetry (which is not authorized by the specification) or it may be a side effect of the failure to implement the notification requirement. That's what I tried to do as well. The DDCMP mechanism is simple. There, the link down notification tells the routing layer to do a circuit down, and the link up notification tells it to begin running the routing layer initialization handshake (Init message, Verify message if needed, and then things are ready). The trouble is that if you do this when the other side routing layer hasn't been told about the down/up cycle, it sees an Init message when it thinks the circuit is "up". That produces a "down", and that end sends an Init message. But it expects an Init message in reply, which this side doesn't normally send because it did so earlier. So this is why I call it a side effect of the failure to implement the correct tie-in between data link and routing layer circuit states. The workaround is to detect this pattern and send the Init message again. I didn't explain it clearly. The old emulation simply sends the data handed down from routing, with a count in front to do the packet framing in the TCP stream. It's pretty much like Multinet except that, since it's a DMC emulation, the tie to the routing layer state is correctly provided. Yes, and as such it isn't really a good choice for any path that has more than a tiny packet loss rate. The assumption DECnet makes for Ethernet is that it is a datagram network (so it CAN lose packets) but that the loss rate is quite low -- the sort of numbers you'd expect to see on a correctly constructed LAN. Bridges of course can introduce loss due to congestion, but if that number is at all significant you're in trouble and DECnet won't be all that happy. The biggest issue is that reaction to route changes becomes slow if there is a more-than-tiny probability a routing update packet is lost. paul