"Random" ProxyId runs into collisions on 'state' event emitters about vrpc-js HOT 4 CLOSED

Yes, that's indeed a problem, thank you for reporting!

I will tackle the issue by prolonging the proxyId to 9 characters and base its generation on nanoid. With that we will have a collision probability of 1% after generating 19.008.000 ids. That should more then suffice for any "regular" application and solve your reported problem.

from vrpc-js.

Branch bugfix/44--random-proxyid-runs-into-collisions-on-state-event-emitters created!

from vrpc-js.

Thanks for picking this up quickly. However, I think you didn't touch the proxyId in VrpcRemote.js, https://github.com/heisenware/vrpc/blob/master/vrpc/VrpcRemote.js#L910 as IMHO the error in our system wasn't caused by a collision of the global IDs but rather the local IDs on the receiving end of a vrpc connection.

If I understood our observed problem correctly, the local proxyId in our local VprcRemote object were generated often enough so that this._cachedSubscriptions in VrpcRemote ran into collisions, not the remote proxyId in VrpcAdapter or VrpcLocal. If your quick calculation leads you to a statement of 1% probabilty of collision, I have to say, watch your step, because nobody will be satisfied if there is a 1% chance that your event listener receives an event it never subscribed to! This is unacceptable in a programming environment. Also, there's an obvious way how to avoid this in VrpcRemote.js line 910: Check for each generated local ProxyId that it's not in use. (Similar to database UUIDs which would first do a quick O(logN) search on whether a newly generated UUID is indeed unique. Not super-expensive but a much stronger assertion that the promised uniqueness is really valid.)

As for how many local proxy IDs in VrpcRemote might get generated: Let's assume a connectware service with 1000 resources. Let's assume it gets disabled/enabled every 6 minutes = 10 times per hour = 240 times per day, this makes already 240K IDs to be generated per day, and now we want to have this running for only 10 days without restarting = 2*10^6 IDs, and for sure we want to not have a 10% chance of collision but we want a 0% assertion that no event listener from this._cachedSubscriptions receives an event that was targeted to a different event listener instead.

from vrpc-js.

So the actual solution was now implemented in commit 312b147 , thanks. Can you publish a version 2.5.2 so that this solution is available as published package? Thanks!

from vrpc-js.