Serial number details in specification

[David Rheinsberg]

Hi

On Fri, May 10, 2019 at 1:09 PM Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> The specification only requires that a message's serial number "must not be zero". Calling it a serial number suggests that each message sent on a connection gets the next available number. But is any level of this pattern required?
>
> In particular, if I have sent a message with serial 5:
>
> - Must the next message have serial 6?
> - Must later messages all have serials > 5 (monotonically increasing)?
> - Must later messages have serials != 5 (no repetition)? If I'm not expecting a reply to the previous message, is it legal to reuse its serial number?
>
> It's obviously easy in most cases to satisfy any of these conditions, but I'm interested in how many are required. E.g. if a client is preparing and sending messages separately, does it need to make sure that they are sent in serial number order? Or if a long-running client uses every possible serial number, does it need to open a new connection to continue sending?

Serial numbers are chosen by the sender of a message. A sender is free
to pick any number they wish except 0. Serial numbers can be re-used.
The bus uses the serial number to track "reply-slots", meaning a
pending method-call is tracked by its sender+destination+serialnumber
combination, and this is used to match the corresponding reply.
Therefore, the only situation where serial-numbers should not conflict
is for multiple method-calls that are pending from the same sender,
because in this case the bus will reject the method-call.

The name "serial" is mostly historical. Many implementations simply
call it "cookie". So yeah, the sender of a message is free to pick any
number but 0. Hence, most implementations use a counter.

Thanks
David