On 1 Aug, 2013, at 01:31, Carsten Bormann <[email protected]> wrote: > Nice work, and I really would like to use this. > > Having done RFC 2687, I can't help noticing that the C bit is in the wrong > place. > You only know whether the frame will be complete or will need to be suspended > at the end, not at the start (or you have to proactively slice everything up, > which is not what a suspend encoding is about). > > Simple fix: As frame end marker, use FE and FF, one for completed and one for > suspended. > > Grüße, Carsten
There are two levels of suspension and resumption here. At the same priority level chunks are interleaved round-robin. That's where the C bit is used, to indicate a final chunk of a message that's been knowingly broken into chunks in advance. This is done when messages are larger than a few Ethernet segments, and round-robin interleaving is deemed appropriate to reduce head-of-line blocking at the same priority level. The other level of suspension and resumption is between different priority levels. A higher-priority chunk can interrupt a lower-priority byte stream at any byte boundary, without advance planning. A chunk is complete when the RECOBS decoder encounters an FF code byte. If the decoder encounters a zero byte at any other time, it recognises this as a higher-priority interruption. The existing state is saved (it's a pushdown stack) and decoding of the higher-priority chunk begins. That chunk ends with an FF code byte -- but before we get to that, it could itself be interrupted by an even higher-priority chunk. In principle the stack of interrupted chunks can be arbitrarily deep, but as a pragmatic engineering decision we limit it to four priority levels, to avoid requiring the receiver to have infinite memory. We feel that the message dependency primitives are sufficient for ordering most messages, where the desired delivery ordering is known in advance (the kind of thing people today often think of achieving using priorities), and Minion's four priority levels then build on that by also supporting unplanned interruptions that are not known in advance. Stuart Cheshire
