RequestIds should support 128-bit values
wildnothing opened this issue · comments
The requestId detailed in the WebSocket API Specification v0 is not scalable as an Integer.
For clients with high numbers of users, assigning a random number has a higher probability of a collision than a String of say, 128 bits. If clients opted away from randomising the Integer, they would need to maintain state on their server instead, which is unnecessary overhead.
I suggest String support so that clients can send through 128-bit values as requestIds, allowing them not to need to maintain state and decreasing the chance of collisions with their subscribers.
More on this here: https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions
I agree with this but another thought would be to make the request identifier the token-pair signature.
0x89d24a6b4ccb1b6faa2625fe562bdd9a232603590x4f3afec4e5a3f2a6a1a411def7d7dfe50ee057bf . Is that not what it maps to in memory anyway? (browser or server)