User talk:Cmcqueen1975

Removing resolved discussion

Hi Cmcqueen1975. Just a minor procedural note: I saw that you blanked your discussion at Talk:KHAZAD after you had fixed the problem in the article you were discussing. (That is, you removed the discussion when it was no longer relevant.) You should not have blanked it, instead you should have noted that you had fixed the problem and thus finished the discussion. Anyway, thanks for fixing the article!

--David Göthberg (talk) 17:34, 19 July 2008 (UTC)[reply]

COBS/R

Hey, saw your COBS comment. Two questions - one, if you have the framing info already, when would you also need bytestuffing? - and two, given that you do already have framing info to validate the final length byte, why the rotation?

Encoded in plain COBS (length code bytes are bold):

03 2F A2 04 92 73 26

Encoded in COBS/R:

03 2F A2 26 92 73

Why not:

Encoded in COBS/R:

03 2F A2 92 73 26

since the odds of the two bytes exceeding the remaining length are the same?

Cheers, Jthill (talk) 06:54, 19 January 2011 (UTC)[reply]

Hello. First question: the assumption is that you're using zero bytes to provide framing. So the packet is terminated by a zero byte. When you decode with COBS or COBS/R, the assumption is that you've already processed the low-level framing, that is, collected the packet of non-zero bytes delimited by two zero bytes.

Second question: good question. The way I've done it, you can decode a COBS/R stream on-the-fly, that is, byte-by-byte with just a 1-byte buffer delay.

First you get the "length" byte value 'n'.
Then you go ahead and copy the next 'n-1' bytes (or less if you get a zero byte first) to output immediately as you receive them.
At the end of that, there are three possible scenarios:

If the next byte is non-zero, you output a zero and then read that next byte as the next "length" byte.
If the next byte is zero, then that is the end of the frame.
1. If you had received 'n-1' bytes as expected, you're done. Output is complete.
2. If you had received less than 'n-1' bytes, then the so-called 'length' byte is actually the last byte of the output. Output it, then you're done.

Your alternative proposal would also work, but would not be able to decode a stream byte-by-byte with a 1-byte buffer delay. You would need a larger buffer to store up to 254 or so bytes until you received the end-of-frame delimiter, before you would know what to output.

Regards, Cmcqueen1975 (talk) 02:43, 20 January 2011 (UTC)[reply]

Ok, thanks. So, the COBS/R decoder has one change from the COBS decoder: on encountering the terminating nul, if there is a remaining length then the original length was not in error but instead is the final data byte. The result is a net savings of one transmitted byte for that packet. The necessary simple change to the encoder follows directly.

Thank you very much, where transmission errors aren't a concern this is so often better it's an automatic choice. --Jthill (talk) 18:24, 20 January 2011 (UTC)[reply]