rsms / gotalk

Async peer communication protocol & library
MIT License
1.2k stars 76 forks source link

RequestId #2

Closed funny-falcon closed 9 years ago

funny-falcon commented 9 years ago

Why requestid is 3 bytes? Isn't it small a bit? Isn't 4 byte more suitable?

gtaylor commented 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.

alimoeeny commented 9 years ago

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

rsms commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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