[HECnet] Re: Surfing DAP Configurations on HECnet

I finished a first cut handling an EOF after configuration.  It took me a little long than expected because the Tops-20 DAP engine implements a kind of nifty finite state machine to handle DAP function requests. The way it works is that you are either waiting on a read or waiting to write.  The former means you've written something to the network and are waiting for a response, whilst the latter means you have the go-ahead to write, but you are getting the data ready and will shortly be writing something. Once the final Access Complete message is sent by the FAL process, it technically might have something further to read, if it were the case that the NFT process had something else for it to do.  However, what it does instead of waiting on a read, is poll for data and, if there is any, it goes and does the function.  A disconnection at this pointis considered acceptable. So I put in code to check to see if an EOF is hit after the finite state machine has exited the configuration state.  If this happens, I attempt to log something 'clever'.  It can be seen the the Tops-20 NFT client is sending some disconnect text to attempt to inform that the remote FAL that the connect was merely because of a configuration query.  4-Jun-2023 00:20:34 File Access Listener 2 Connection from node *VENTI2* for user Anonymous  4-Jun-2023 00:20:34 File Access Listener 2 Validated node *VENTI2* for user id OINKY Post Configuration close: "/ConfigQueryOnly/", Reason: 42 (Confirmation of Disconnect Initiate)  4-Jun-2023 00:25:01 File Access Listener 1 Connection from node *MIM* for user Anonymous  4-Jun-2023 00:25:01 File Access Listener 1 Validated node *MIM* for user id Anonymous Post Configuration close; Code: 0, Reason: No error The question in my mind is what disconnect code to use, if any. I had initially thought a 42 was the thing to do, but the more I think about it, the less correct it seems.  Moreover, it can be seen that MIM:: is closing with a zero, which indicates no error.  There's certainly the case for that, but I'm wondering whether the question remains as to whether this early termination is something to be signaled on the disconnect. I don't suppose there are any other DAP clients that do what RSX and Tops-20 NFT do? I did come up with a possible use case where you would want to connect, query the configuration and use that to decide whether to proceed further.  It's simply that you need to use a resource or perform a function that you are not going to bother to do if the machine can't do it.  So that sounds like a variation of an availability scenario, albeit contrived, perhaps.