2 Jun
2023
2 Jun
'23
8:13 p.m.
On Jun 2, 2023, at 12:14 PM, Thomas DeBellis
<tommytimesharing(a)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.
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.
paul