Incorrect server handling of x38 request rejects all RDDIR and RSFILE subfunctions

[ted4277]

The server code for handler for x38 has a limit check on the subfunction rejecting a MOOP > RDFILE.

The server should accept RDDIR and RSFILE. I suspect this is a simple typo where RDFILE was typed instead of RSFILE by mistake.

[driftregion]

Thanks. I have updated the limit check to be easier to read in #118. RDDIR and RSFILE are not supported on the server yet.

[ted4277]

Thanks for your fixes - I think this library code is remarkably readable, maintainable, adaptable...all around excellent!

As to RDDIR, your server may not support RDDIR but any other user's application layer, IMHO, should determine whether the MOOP is supported. The server code itself should be compliant with the standard (including RDDIR), and an unsupported service NRC can (and should) be returned by the event handler for a bad MOOP, like it would any NRC such as bad file name, etc.

Just my opinion - Thanks again

[driftregion]

Thanks for your fixes - I think this library code is remarkably readable, maintainable, adaptable...all around excellent!

Thanks! That's great to hear.

As to RDDIR, your server may not support RDDIR but any other user's application layer, IMHO, should determine whether the MOOP is supported. ...

I fully agree. I took a look yesterday at implementing tests for RDDIR and RSFILE and getting it right needs more time than I want to give right now. RDDIR should be straightforward for the reasons you mentioned but I haven't wrapped my head around how RSFILE is supposed to work yet.

[ted4277]

Thanks for your response...I don't know how one would implement RSFILE (resume) but I would venture a guess the intent is like the REST command in RFCs 959 and 3659. Is ISO 14229 clear on this on byte offsets, BCNs, etc? Perhaps the response to RSFILE MOOP gives the "size" of the file on the server, and expects to start at bcn #1 and simply append? We don't need it fortunately.

On another note we needed the ability for the server handle the client a data transfer request timeout...basically by expecting the client to resend the x36 request with the previous block #. This issue took all of one line of code to just return PositiveResponse thus retransmitting the previous r.send_buf contents unchanged. Yes I know there is a risk of other unrelated requests clobbering r.send_buf but we can cope with that procedurally...very simple.

if ( (uint8_t)(blockSequenceCounter + 1) == srv->xferBlockSequenceCounter )

-Ted

ps. MOOP reminds me of old Seinfeld episode, funny