[Vortex] Is vortex assuming that msg numbers on channels start at 1 and increase by 1/

[Francis Brosnan Blazquez]

Hi Sam,

> I read the report, I don't think it describes a fix to the problem, it
> describes a fix to the opposite of the problem I saw.

Ok, I did put the focus on the API update rather in important part of
the update required to fix the problem, that is, allowing *receiving*
MSG frames reusing message numbers.

> What vortex does in terms of its message number **allocation** is
> standards compliant, and as far as I know, works with other BEEP
> implementations. 

Here we differ Sam. We have two completely different aspects of the
message number allocation here: 1) how the BEEP toolkit implements its
message allocation pattern (SEND) and 2) what should be supported by the
implementation to accept message allocation patterns for other BEEP
toolkits (RECEIVE).

At this moment, Vortex has a compliant MSG number generation, but it do
not support *all* allowed patterns. So, we are compliant while sending
MSG, but not when receiving...

In the other hand, the fact Vortex works with other BEEP
implementations, in terms of message number generation, only means they
chose a sane pattern, but, technically, they (including vortex), should
allow receiving the message 5 then 659 and then 3. I suspect no BEEP
implementation supports this at this moment.

> It certainly works with beepcore-c, doesn't need any
> modification, and certainly not some user-controlled message number
> allocation system! Yuck! ;-)

;-)) Ok, I'm with you this is not the point. I'm sure nobody cares about
reusing MSG numbers from the API, but the core work to make this happen
is still there (providing this API is just the tip of the iceberg).

I was just proposing this API update to control message number because
it is consistent with the RFC.

> I assume vortex already tracks which MSGs it has received on a
> channel, so it can know which message numbers the local API user is
> allowed to send a RPY, ERR, ANS, or NUL to.
> 
> All you need to do is when a MSG is received on a channel, make sure
> that it's message number is NOT among the currently active message
> numbers (instead of whats done now, which is to make sure its equal to
> the number of the last MSG + 1, which is wrong).

Right. 

> My comment about message number reuse was just illustrative of how
> flexible the RFC is in how implementations can allocate message
> numbers. I haven't actually seen a beep core reuse message numbers
> (even for wrapping, because have never waited for more than 2147483647
> messages on a channel...).

Ok. Thanks for your comments Sam!

-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.