14 Jan
2026
14 Jan
'26
6:08 p.m.
Maybe I should make a few more comments.
There might definitely be something VMS specific in your observations. I
wouldn't know.
With TCP/IP, when data is sent, it's going to be in the queue and be
delivered even if the sending process closes, finishes and goes away.
The end-of-file is queued into the sending stream after all the data
that was sent.
With DECnet, the underlying transport is always record oriented.
Anything that looks like anything else is always just trying to hide
that fact. And when you send something, you'll get an indication when
the send is completed, at which point it shouldn't be possible for it
not to be delivered, unless connection have completely been lost. With
RSX not even that is possible, since a completion of a send means that
the receiving side actually completed the receive. It's very synchronous.
If some higher level library hides all of this, then I would expect it
also have a way of telling if all the I/O have completed.
Basically, server side accepts the connection, reads the single request
line, and then sends data until it is done, after which it closes the
connection. There must be a way to know that the data is actually being
delivered, so you don't cancel outstanding sends if they are done
asynchronous.
Johnny
On 14/01/2026 18.00, Johnny Billquist wrote:
Hum?
I'm not sure I get it.
The client does a connection to the server. Sends a single line. Reads
until it gets an end-of-file/connection-closed indication when readind,
at which point the server is already gone, and the client can finish.
Where are you thinking/seeing that you need to wait for anything?
Johnny
On 14/01/2026 17.58, Keith Halewood wrote:
There's a simplistic version currently
running on DUNE::
I've noticed a few problems with it.
For transparent DECnet I/O where channels are assigned and I/O happens
as though each end is local, DECnet seems to suggest that the
receiver (finger client in this case) should disconnect when it has
received what it expects to receive. This expectation should be part of
the client/server protocol such as an explicit end of data record.
In the TCP/IP world, a finger server disconnects when it's finished
sending all that it wants to send. There's no explicit high level
protocol
stating end of data received by the client other than a receive
succeeding with zero length response.
Even with explicit $QIOW (waiting for I/O to complete), a DECnet
finger server will $ASSIGN to the incoming connection, do a few $QIOWs
and
do a $DASSGN, which is quite destructive, including cancelling all
pending I/O requests. You would think that a $QIOW would return when
the I/O
completes end to end but it seems to complete when DECnet takes over.
Consequently, on slow links, a $DASSGN could cause DECnet not
to transmit data that's still pending. This is currently happening on
a comparatively slow link between DUNE and and a host in Australia.
The non-transparent case, where a lot more of the DECnet handshaking
is exposed, offers a synchronous disconnect which is initiated with
a $QIOW. The server would send this and the client would then have to
react as though it had received an EOF. In other words, it seems that
both
ends need to be non-transparent.
A lot of this may be peculiar to DECnet on VMS which tries to hide
much of the complexity unless you go for full non-transparency. Even
then you
can treat the connection as record-orientated even though it's not
like that underneath, and listen for events on the attached mailbox
device.
I really don't feel like doing $ASSIGN, $QIOW(read), a series of
$QIOW(write), then a wait for an unknown amount of time before $DASSGN.
Judging by some of the behaviour I've seen with user DECnet tasks
implemented by command procedures, that appears to be what VMS does
sometimes.
Is this what networking used to be like? Weird?
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 14 January 2026 13:42
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet Finger Specification (Possible re-post)
and Tops-20 Finger Setup Documentation (New)
On 14/01/2026 14.36, Keith Halewood wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Regarding finger for VMS, I have no real
recollection of how we used
to gather idle time for the 'job' (collection of process and
subprocesses attached to the terminal).
Back in the university days, some of the VMS systems had a small fixed
number of lines connected to the Gandalf (a terminal server/switch)
so we had to do something to prevent users hogging the lines.
I think we used to enumerate allocated terminal class devices every 10
minutes and remember their completed I/O counts. If the count hadn't
changed since the last sweep, then the user was logged out. There may
have been other considerations involving CPU time, etc. but as I said
the details are permanently paged out of my memory. I don't think the
above would be any good really for finger idle time.
I think this is one of those topics which I would just leave as
implementation specific. It depends on what the OS does, and what can
be easily extracted. Just present users with whatever information
makes sense. THe finger protocol is meant for human consumption, so
there are no hard requirements on what information is provided, or in
which form.
"Idle" in RSX is defined slightly different than in Unix or VMS. I can
tell you that much. But I can only report what RSX thinks here. (If
you were to hit enter on a terminal in RSX, you are still considered
idle.
No activity happened.)
I have the beginnings of a DECnet finger server
for VMS in Pascal,
which will produce summary information for who's logged, when, what
they're doing and where they're doing it from and also specific
information for matched users if supplied as a parameter, including
plan and the read/unread status of their mailbox. I won't do "poor
man's routing"
and I'm tempted to restrict the breadth of partial searches to a
complete username and/or complete word components of a user's real name.
This is also something I'd happily leave to each implementation. PMR
or not - up to each implementation. Just give some sort of error if
you don't allow it. Same with user matching.
It'll fit into the framework I have for a
DECnet server that declares
itself as an object and remains running, handling multiple
requests... but who wants a finger server hanging around?!
I don't, so the initial version will be instantiated on incoming
request.
That's how I do it in RSX, and that's how Unixes does it as well. I
think it would be the most sensible way to do it.
It'll be on DUNE's default DECnet account
if/when I finish it.
Would be nice to see it in operation.
Johnny
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se