Closed funny-falcon closed 9 years ago
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.
Using UUIDs sounds like a good idea. Not having collisions over long periods of time over different communication channels can open unexpected possibilities.
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?
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.
v1 landed in master and the protocol now uses 4 bytes for requestID
Why requestid is 3 bytes? Isn't it small a bit? Isn't 4 byte more suitable?