21 Nov
2022
21 Nov
'22
11:52 p.m.
On 2022-11-21 20:53, Paul Koning wrote:
You forget fast. :-)
Here is what I wrote in August this year:
==========snip=========
Paul. Back home and able to check things.
This is rather interesting, and way more complicated, it would appear,
from reading the RSX sources.
Starting with the client that connects to VMS:
CMPB #1,CNFBUF ; IS IT A CONFIGURATION MESSAGE
BEQ 100$ ; IF EQ, YES
90$: CALLR ERR17 ; ISSUE ERROR MESSAGE
100$: BIT #4,CNFBUF+6 ; DOES REMOTE SPEAK VMS PROTOCOL
BEQ 90$ ; IF EQ, NO
So this seems to align properly with what you described.
Now, looking at the client that connects to RSTS/E:
First some definitions:
;
; REMOTE DEVICE PROTOCOL DEFINITIONS
;
; DEFINED FOR RSTS NETWORK TERMINAL PACKAGE, "NET" AND "NPKDVR"
;
.ASECT
.=0
R.TYP:: .BLKB 1 ; MESSAGE TYPE
RT.CFG==1 ; CONFIGURATION MSG
RT.CTL==2 ; CONTROL MSG
RT.UNS==3 ; UNSUPPORTED MSG
RT.CON==4 ; CONTINUE MSG
RT.DAT==5 ; DATA MESSAGE
R.LEN:: .BLKB 2 ; MESSAGE LENGTH
RM.HLEN==.-R.TYP ; LENGTH OF MESSAGE HEADER
R.RES:: .BLKB 133. ; REST OF MESSAGE (SEE BELOW)
RM.MAXLEN==.-R.TYP ; MAXIMUM MESSAGE LENGTH
; (ACTUALLY RSTS SENDS LONGER MSGS --
; UP TO THE NSP MAX MSG LENGTH.
; BUT THIS IS THE MAX WE EVER SEND.)
;
; CONFIGURATION MESSAGE
;
. = R.RES ;POINT TO REST OF MESSAGE (ABOVE)
R.OST:: .BLKB 1 ; OPERATING SYSTEM TYPE
RO.RT==1 ; RT-11
RO.RST==2 ; RSTS/E
RO.RXS==3 ; RSX-11S
RO.RXM==4 ; RSX-11M
RO.RXD==5 ; RSX-11D
RO.IAS==6 ; IAS
RO.VMS==7 ; VMS
R.VER:: .BLKB 5 ; VERSION NUMBERS
R.MOD:: .BLKB 1 ; SESSION MODE
R.MNU:: .BLKB 1 ; MENU FOR REST OF CONFIG MSG
; (NO MORE DEFINED NOW)
And then the code:
CMPB #RT.CFG,CNFBUF+R.TYP ;* IS IT A CONFIGURATION MESSAGE
BEQ 40$ ; IF EQ, YES
20$: CALL ERR17 ; ISSUE ERROR MESSAGE
BR 70$ ; PROCEED
40$: CMPB #RO.RST,CNFBUF+R.OST ;* DOES REMOTE SPEAK RSTS PROTOCOL
BEQ 45$ ;* IF EQ, YES
CMPB #RO.RST,CNFBUF+4 ;* RSTS PROTOCOL WITH STANDARD CFG?
BNE 20$ ;* NO, REJECT THIS HOST
45$:
So here, the code checks the OS type, and in fact seem to claim that +6
is in the version value area. No bitmask for different protocol styles.
I'm also wondering why it checks CNFBUF+R.OST, and if that fails, it
checks CNFBUF+4, which is the same thing.
Looking at the TOPS-20 client, there don't seem to be any system
checking or init message at all.
And indeed, if testing, I can connect to MIM using the TOPS-20 client.
However, as soon as I type anything, I get disconnected. Probably
because the RSX server expects an INIT message, and none is coming.
Finally, RSX client to RSX seems to match the VMS pattern, with both OS
type and a bitmask in the next word telling protocol type.
Based on this, I would say that conflating the different clients into
one seems almost impossible.
==============snip=============
So basically, the TOPS-20 NRT server is not sending anything when you
connect, and the RSX NRT client for connecting to TOPS-20 is also not
expecting anything. And the other clients I have do things in different
ways.
But by that reasoning, all RSX-11/M variants should use the same code, and likewise
RSX-11/D and IAS should share a code. After all, they are essentially the same OS...
Well. Depends on how you look at it. You could just as well argue that
this supports my point.
With RSX, it is shared source, but the actual behavior in the systems
actually differ.
-11M only have UIC based directory names, octal version numbers, and
just simple device names.
-11M-PLUS have UIC and also named directory names, decimal version
numbers, and full logical names. Very close to how VMS looks and feels,
basically, except no subdirectories.
(And I won't even talk about -11S)
So common source is not really a good way to group things by. Makes more
sense to talk about the behavior and properties.
But I would agree that -11M, -11D and IAS could probably very well have
shared the same id.
On Nov 21, 2022, at 2:41 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-11-21 19:26, Paul Koning wrote:
Yeah. NRT is a bit odd. And unless I remember wrong, some variant don't even send
anything at the start, so it's even more screwball to identify what you should try and
speak.
I haven't seen any NRT servers that fail to send a config saying what flavor they
are. Only the server does; the client expects the server to speak first after connection
is made. On Nov
21, 2022, at 1:17 PM, Thomas DeBellis <tommytimesharing(a)gmail.com> wrote:
Interesting; I was wondering why you picked a special number? I would imagine that most
implementation wouldn't know it and maybe Ultrix-32 (OS$U32==^D18) might have been a
better choice? Ultrix-32 is of interest as its NRT is compatible with Tops-10/Tops-20 and
has the same OS type number.
NRT is a bit of a strange case because it's 4
protocols packaged inside a single DECnet object number. So the actual protocol is
identified in the first message sent by the server. The client then must use that number
to dispatch to the correct protocol machine (or abort if it doesn't have one). The OS number in NRT, on the other hand, is just
information and should be ignored just like it should be ignored in every other protocol.
Right. Once you have some data, there is better information than the OS identifier.
As for "special" do you mean the value
192? The DAP spec explicitly assigns the range 192-255 for "user-specified operating
systems". So for an NFT to fail when it gets that code is a major protocol
violation. Identifying Linux as Ultrix would be misleading, they are quite different
operating systems with no common ancestry or code base.
I'm not sure I agree. While I don't mind grabbing some undefined/reserved number
for a new implementation, Linux is after all just another Unix in this sense, and would
suite very well into just pretending to be Ultrix. Shared codebase seems rather
irrelevant. It's much more about the actual properties and behavior of the system. I
generally always group all Unix-like systems together. There are some times when you want
to differentiate between them, but for network protocols like this, I can't think of a
single reason.
In a sense, they have a very shared ancestry. In any case, the main point is that OS code 192 is a
code with a well defined meaning, so for an NFT to complain about it isn't simply a
violation of the "be lenient in what you receive" rule, it's a direct
violation of the definitions in the protocol spec.
Agreed.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol