21 Nov
2022
21 Nov
'22
8:53 p.m.
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.