> On Oct 9, 2015, at 9:38 AM, Johnny Billquist <b...@softjar.se> wrote:
>
>>> ...
>> Phase II use NSP v3.1 so that’s probably another indication that it’s a
>> Phase I product.
>
> John, maybe you can clear some things up for me.
> Looking at the Wikipedia article about DECnet, it claims that phase I was
> simply between two nodes. No larger than that. And in addition was RSX-11
> only. And it was 1974.
It wouldn't be at all surprising if the information about Phase I were
inaccurate given its undocumented status.
> Phase II says multiple implementations on different systems, and a max of 32
> nodes. Also supposedly added task-to-task programming interfaces. And
> supposedly 1975.
>
>
> Now, looking at the DECNET/8 documentation, there is some discrepancy here.
> DECNET/8 supports up to 127 nodes. It only have point-to-point links, but it
> clearly have some idea of dealing with several hops to reach the destination.
> It also obviously have task-to-task programming interfaces, which looks very
> similar to what I know from phase IV.
>
> Now, I'm happy to believe that Wikipedia is just plain wrong, but it would be
> interesting to hear if you can provide any more details to what phase I and
> phase II differed on, and where DECNET/8 would fit based on that.
I looked at the document you sent. While it has some hints about the protocol
in chapter 6, it doesn't come close to telling us what's necessary to build a
compatible implementation. DDCMP might be compatible; the bits of packet
layout given on page 6-4 seem to match those of the later DDCMP specs.
NSP, on the other hand, clearly is not compatible. Again, there are only hints
of packet layouts -- only some of those are shown and their semantics not
described. It has an optional routing header just as Phase II does, but
encoded differently. And the message type field (MSGFLG, first byte of the NSP
message header proper) looks somewhat like that of later versions of NSP but
the encoding is substantially different. The Connect message looks vaguely
like a later Connect Initiate, but the details are quite different. Based on
what little I can see, the statement in the Phase II spec that Phase I was
incompatible (implying "it's not feasible for a Phase II node to interoperate
with a Phase I node") is indeed accurate.
The normal case of Phase II was that it allowed communication only between
adjacent nodes. A given node could have multiple interfaces, presumably
connected to different neighbors, and it would use the destination address of a
packet to choose the correct interface on which to communicate. The same
would, I assume, apply to Phase I.
Phase II had an optional routing header for something called "intercept"
operation. The DECnet/8 document describes the same sort of thing though the
encoding is different. I can't tell if DECnet/8 could actually supply routing
headers; it does say clearly that it would not act on them. Similarly, most
Phase II implementations didn't handle routing headers either (would neither
generate nor accept them). The Phase II spec is not all that clear on how they
are supposed to be generated or used, in fact. I vaguely remember that TOPS-10
(or -20?) used them, with the front end processor acting as the forwarding node
and the main CPU as endpoint. So communication would be two hops: PDP-10 to
front end to other node. While theoretically there might be more hops, in
practice that didn't happen. For one thing, Phase II NSP doesn't appreciate
lost packets.
In Phase III all that changed, with a real routing protocol, clearly documented
routing operation, and an NSP that would do retransmission to handle lost
datagrams.
paul
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
