On 2015-10-09 17:01, Paul Koning wrote:
On Oct 9, 2015, at 9:38 AM, Johnny Billquist <[email protected]> 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.
Yeah. Like I also said. Would not at all be surprised if Wikipedia is
very inaccurate.
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.
All this said - look at the nodename table in DECNET/8. There you can
see that the entries gives the node name (6 characters), the nude
numbers (7 bits), a flag bit saying if the node is adjacent or not, and
a link number.
So clearly it can communicate both with direct neighbors, and hosts
further away, and it knows which link to send packets on if it is not an
adjacent node. It also says you can leave the nodenumber at zero if
unknown, if the node is adjacent, suggesting that it will figure out the
node number of adjacent nodes on its own as well. But for non-adjacent
nodes you really need to populate the table properly.
Semantics are not at all clear in that document. I have the code as
well, if you'd like to read some PAL8.
There is obviously no routing protocol here, which tells us this is not
phase III (not that we ever thought so to start with).
Johnny
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
