Serial number details in specification

[Thomas Kluyver]

Thanks David for the speedy reply; that makes sense.

On Fri, May 10, 2019, at 12:16 PM, David Rheinsberg wrote:
> 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
>