On Tuesday 30 September 2008, Daniel-Constantin Mierla wrote:
[..] Sure, it's great if my registrants always go to the same location server, but if 90% of my users end up going to one location server because of the distribution that the variance of their From URIs provides, what does this really give me except a predictable route? It's not as if I can use the hash to "find" a user's location server -- unless the location server was determined using the same hash also. What's the point?
The hash function was tested to get pretty fair distribution for AoR, most of the hashed values respect this format. If 90% of your users end up to same server, then you may need to code a bit :-) and add an alternative hash function to the module. For me the existing one seems good so far.
I do not need to know where a user call is going. Practically, they could share the same db backend for auth, but the location and other user profiles details may be in memory for speed purposes. In what I am doing, all the servers in a group have same config, if i add a new one, I get a new dispersion of the users across servers.
Getting the distribution is quite simple, take the has function and make a simple app that takes as parameter a string and outputs the hash value. Knowing your subscriber base ids, you can estimate the results of dispatching.
Hi Alex,
don't that much about the dispatcher internals, but i think it also uses the CRC32 hash. In my tests with the carrierroute module that uses this too, requests over a random callid/ from user are distributed equally with about +/- 5% accuracy, which i think is ok. If you need to adjust the target host distribution, take a look at the hash_id functionality (carrierroute config file mode), here you can specify the exact destination. We use also the this approach of pre-calculating the hash value that Daniel described.
Cheers,
Henning