11 Jan
2026
11 Jan
'26
4:24 p.m.
A couple of small comments on some additional bits...
On 2026-01-11 09:53, Terri Kennedy wrote:
RSX just gets packets. TOPS-20 just stuffed multiple lines into one
packet. At some point, it created packets larger than my receive buffer,
at which point I got truncated data.
True, but that requires the host database to be populated and for
sites to keep it up-to-date.
Please be aware that RSX does not allow you to specify node numbers in
any APIs. So basically, not an option on that side. You always need a name.
Seems reasonable. Dual-stack (or more-stack) implementations just
have to
recognize their own name in whatever it might be. Like the previous item,
not mandatory, not prohibited.
Following RFC 1288, the next hop *should* be removed.
So if the user types "finger user@foo", the client should connect to
host foo, and only provide "user" as the request. And by extension, if
the user types "finger user@foo@bar", the client connects to host bar,
and gives the request "user@foo" to the finger server.
Please read through the RFC if you want more clarity around this. And I
truly think we should just behave the same with DECnet.
So if someone types "finger mim::venti2::slogin", the client should
connect to MIM, and give the request "venti2::slogin".
IPv6 and its use of :: is also going to be a can of worms. I'm hoping to
avoid IPv6 until I'm beyond caring. 8-}
This shouldn't really cause any problems. Any IPv6 :: thingy would occur
after an '@', while any DECnet node would appear before.
I don't know what the VAX code is doing. But I can tell you that the RSX
client is really just sending a CR+LF here. And yeah, I'm getting a
whole lot of strange errors just like Thomas.
On 2026-01-10 23:11, Thomas DeBellis wrote:
Ok, so you're talking about putting "STREAM" in the "magic 16
bytes"
or whatever it is that can be set by an application using DECnet? I had
thought you meant it should be on the command line.
I guess with the "magic 16 bytes", we're talking about the optional data
that can be provided with a connect call. They have no predefined
meaning, and each application can do whatever in there. There is no
"stream" interpretation in it. Streams under TOPS-20 is basically just
that multiple writes gets combined together into a single DECnet packet.
And I guess on the receiving side, you can read "lines", and the
unpacking from packets is happening in an intermediate layer.
On
1/10/26 9:50 PM, Terri Kennedy wrote: A few observations:
1) How is a request for streaming output on an otherwise empty
request differentiated from a request for info on a user named
STREAM? I suggest /STREAM for this reason.
The difference lays in considering what is application data and what
is meta-data. A server is under no obligation to do anything with the
meta-data, which is to be found in the connection attributes. Sothe
optional DATA attribute is only used to condition buffering for the
client. The USER attribute is to log the remote user making the
query, not the local user. The user information being requested is
always passed in on the connection as application data. So user
STREAM would show up to the client's input buffer as "STREAM^M" (or ^J).
A potential
concern with a /STREAM switch is that the user could then
issue it and break an RSX connection. Unless debugging is on, the
connection attributes will not be seen and cannot be invoked from the
command line.
If it's in the metadata, then it isn't an issue. My misunderstanding.
Although in the case you're describing, sending /STREAM to an RSX sys-
tem from a -20 would just be ignored. Or are you describing what could
happen if a user on RSX said "finger node::somebody /stream" to a -20,
in which case the situation you describe might happen. Although if the
-20 tried to stream to RSX, wouldn't RSX abort the connection? 2) I suggest allowing explicit area.node:: syntax.
I think that could be made an option, but what is it buying you? The
whole point of the symbolic host name is to not have to remember that
stuff. 3) "Application Level Routing" - neither
RSTS/E nor VMS DECnet allow
HOST1::HOST2::USER syntax. There is also the issue of passing the
complete command line or editing it. If we are HOST1::, do we remove
HOST1:: from the command line before passing it along? I think so,
but this also complicates interoperability as discussed in the
following paragraph:
The paradigm is that you remove whatever you action. So if
from
TOMMYT::, I do a FINGER MIM::VENTI2::SLOGIN, then the MIM:: is removed
from the application data stream and MIM:: only sees VENTI2::SLOGIN. This also gets into DECnet / TCP/IP interoperability,
which I think
should be deferred to a second revision to the spec, or an addendum
to it.
Application level routing is optional. Should this be stated more
emphatically? For Tops-20, it mainly exists for debugging odd cases
to determine robustness. Poor man's routing is a holdover from
previous versions of Tops-20 DECnet that didn't have it. Tops-20
removed Poor man's routing for the terminal server. Hooks exist for
FAL, but I have those turned off. To me, "finger client" is the thing that
the user is using to ask a
remote
"finger server" about user(s) on it.
Since we have multiple implementations, we don't know what options a
remote
finger server might implement (or not).
This is similar to both FTP and SMTP, where the client can ask the
server
what commands it supports. Grated, those are back-and-forth interactive
dia-
logs, compare to the "write a line and get a response back" operation of
Finger. But it is still good to know the capabilities of the remote host.
Agreed. Pass any switches on which aren't obviously something to deal
with locally.
And yes, my RSX implementation should be doing ok there. But let me know
if you spot any issues.
And I think that should be an implementation option
as well, whether a
host will list all users or only by username.
I think that's not unreasonable, but I think that's up to each
implementation how they want to do things.
We can all
push back and have a think. That's really fine. Again,
it's a hobby, so no rush. I also stumbled over some bugs while doing
all this, but that's not any news...
It has certainly exposed some interoperability issues in my code. I
don't
know why both RSX and -20 are getting that spew from spcvxa:: or spcvxb::
listing all of the qualifiers when they just sent a blank line. I suspect
the VMS implementation may not treat all 3 line endings in your draft as
valid line endings. However, I'd like to see what agreement we can
come to on the use of
qualifiers, leaving certain things up to the implementation, and whatever
other points I raised above (3:35 AM now, so time for bed). Feel free to
cogitate and let me know what you think, and I'll look at it sometime
tomorrow, likely at night.
I think passing unknown, as well as qualifiers that obviously makes more
sense to process remotely over on the request line is very reasonable,
and the same thing I'm doing.
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