Somehow I missed this email.

Make sure you are looking at Draft 014 of the spec.  I remember that there was a small bug (in the spec) about one of these ALPs, which I corrected in Draft 014.  I will look at this a bit later and verify that everything is OK, but I just want to make sure anyone following this thread knows about the change in Draft 014.

On the DASH7 Kavi webspace, there is a change-list between 012-013-014 in the form of commented spec files (PDF).  You can view the comments in most PDF readers (I have tested Adobe Reader, Apple Preview, and Skim).

Best,
JPN


On 15 Nov 2011, at 03:26, Matti Nordström wrote:

Hello,

I've been testing the filesystem ALP and I found some possible discrepancies between the functionality in alp_filedata.c and the specification. Especially in the response messages.

Read data message
The response message to Read data message contained only the read data in the payload, but according to the spec (draft 14 p. 80) the message should also always contain the File ID, Start Byte Offset & Bytes Accessing bytes as well. Here is my proposed fix to this:

else {
    limit = (limit > fp->length) ? fp->length : limit;

    if (inc_header) {
        if ((out_q->putcursor+6) >= out_q->back) {
            goto sub_filedata_overrun;
        }
        data_out += 10; /// AGAIDI. Add the offset & span bytes as well
        q_writeshort_be(out_q, vworm_read(header + 4)); // id & mod
        q_writeshort(out_q, vworm_read(header + 0));    // length
        q_writeshort(out_q, vworm_read(header + 2));    // alloc
    }
    else {
        /// AGAIDI. The response should always have the file ID, start offset & span according to the spec!
        data_out += 5;
        q_writebyte(out_q, file_id);
    }
    q_writeshort(out_q, offset);
    q_writeshort(out_q, limit/*span*/);
    for (; offset<limit; offset+=2, span-=2, data_out+=2) {

The read data message handling still has one bug that haven't fixed. According to the spec (p. 79) when the Bytes Accessing byte is 0, all bytes until the end of file should be accessed. This does not happen at the moment, instead no data is read.

Write Data message
According to the spec (p. 79) an error message should always be returned when the respond bit is on, even when no error has occurred. This was not the case though, instead a corrupt ALP message was sent. Here's my proposed fix:

sub_filedata_senderror:
/// AGAIDI. We must always send an error response when response bit is on AND a write message is being processed
/// regardless of the error value!
if (respond && ((err_code != 0) || (file_mod & VL_ACCESS_W))) {
    if ((out_q->putcursor+2) >= out_q->back) {
        goto sub_filedata_overrun;
    }
    q_writebyte(out_q, file_id);
    q_writebyte(out_q, err_code);
    q_markbyte(in_q, span);         // go past any leftover input data
    data_out += 2;
}


Were these actually bugs in the code or are the errors in the specification (which means I just wasted my time fixing these :D ) or am I completely wrong here?


Matti Nordström
Agaidi Oy
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
Opentag-developers mailing list
Opentag-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opentag-developers