[HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger Setup Documentation (New)

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: 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.) 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. 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. 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