On 20/10/2016 09:03, Michael Richardson wrote: > > Brian E Carpenter <[email protected]> wrote: > > MR: Given that CBOR has only 1,2, and 4 byte uintegers, why do we have > > a 24-bit session-id? > > > BC: Well, it's a hangover from the pre-CBOR TLV format. But I think > > it's true that we'd increase the average message size by making it 32 > > bits, since there are a lot more random numbers between 2^24 and 2^32 > > than between 1 and 2^24. > > > MR: okay, hangover that you'd like to save a byte. But CBOR doesn't > > let you save that byte, so just make it uint32? > > > BC: CBOR sends 1, 2 or 4 bytes according to need, as I understand it. > > If my session-id is 0x010000, then CBOR will send 4 bytes. > In the unlikely (1/2^27 + 1/2^24 + 1/ 2^16 chance, less than 0.001%) that a > randomly generated > session-id has two or three leading zeros, or is less than 24, CBOR will send > fewer bytes. (I think, sending more bytes is still permissible). > > In most cases, it will send 4 bytes, so might as well use them.
Yes, I think you are correct. An easy change if people agree. > See my email today about perhaps using bit 31 to partition the session-id > space between TCP sender and receiver. As I said, I don't really see the issue there. According to https://tools.ietf.org/html/draft-ietf-anima-grasp-07#section-3.6 the negotiation (or synchronization) session has its own session-id, distinct from the one used for discovery, even if they did re-use the same TCP session. Messages for the two transactions (discovery and negotiation) could be demultiplexed using the session-id, even if they overlapped in time for some reason. The ids will never clash, because the same party initiates discovery and negotiation. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
