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 point is 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 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.
On 6/2/23 2:13 PM, Paul Koning wrote:
Good point. The spec is no help here. The protocol description (DAP 5.6.0 section 5.1.2) shows that client and server send config messages after the NSP connection is opened. But then part 3(c) shows a config exchange immediately followed by an NSP disconnect as a the scenario for the client deciding the server's config message is invalid. That's really a spec error; there is no way I see in the protocol to open a connection and then decide not to do any data operations after all. So given that bug in the spec, suppressing the error log message is the right answer. I see I did the same in PyDECnet: after the config exchange, it looks for a message to say what data transfer to do. A disconnect at that point simply causes FAL to exit.
On Jun 2, 2023, at 12:14 PM, Thomas DeBellis <tommytimesharing@gmail.com> wrote: Yes, there is always some poor soul who will haplessly manage to trip over cables, even if they are under a raised floor. So, there is that--connections can drop. That wasn't quite what I was getting at. What I meant was generating an error condition which maybe ought not be there had the closure been done 'the right way'. Right now, because I just punt the connection as soon as I get the configuration goodies, I see a premature EOF in my log files. Not the end of the world, but I was wondering about not having it be there. So I was thinking about sending an access complete message after the configuration exchange, but that doesn't seem to be what it was designed for in this case. The last part of section 5.1 seems to imply that a disconnect after a configuration exchange should be rare as errors will be rare due to the "canned" responses. So maybe I'm thinking about this the wrong way. Another approach would just be to not log a premature-EOF error on a disconnect after a configuration exchange. I'll look into that.