RequestId

[rsms]

RequestId

[gtaylor]

Selfishly, I'd love to be able to use UUIDs, but that may be overkill. In either case, we're not talking about a massive amount of overhead (3 vs 4 bytes, or 3 vs 16 bytes for UUID). I'm still not 100% sure how the request IDs should be generated, but I'd definitely want to avoid collisions.

[alimoeeny]

Using UUIDs sounds like a good idea. Not having collisions over long periods of time over different communication channels can open unexpected possibilities.

[rsms]

TL;DR: 3 bytes (16 777 216 values) is enough.

3 bytes is simply enough for anything I could imagine. If you have an application which might send more than 16 777 215 requests in between a request being sent and responded to, you might want to use two or more connections (one for the very very slow requests and one for the very high-frequency requests.)

The ID has the potential to express 16 777 216 values, while the current Go and JS implementations only use 46 655 values (base-36 encoded integer.) UUID does not only require a large number of bytes to be represented, it is also expensive to calculate (needs a pool of true random data, etc.) Incrementing an integer is very cheap and easy to implement.

Is there a scenario you have in mind where an application might perform 16 777 216 requests in such a close succession that the first request does not have time to complete before the 16 777 217th request is sent?

[funny-falcon]

46655 certainly not enough. Use at least base64 if you wish to use text only id.

Lets calc: 1000000rps of light requests and 1 request which lasts 17 seconds - then 16M will not be enough either. Yes, it is strange combination, but 4 bytes is 256 times more reliable.

[rsms]

v1 landed in master and the protocol now uses 4 bytes for requestID