-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hash_b explanation incorrect? #12
Comments
Yes, i face the same problem, here is a example
then the result of |
Hi all, sorry for the delay in response, I've just started a new job and have been pretty busy this past week. You're both right - that situation would cause the same issue. However, I ~ think ~ that this problem can be avoided by choosing a Does that sound correct to you? If so, I'll definitely add this info to the tutorial. |
I'm having this same issue but I don't quite understand your proposed fix.
I'm not "choosing" a hash_b. I'm using ht_hash to calculate hash_b using the string, HT_PRIME_2, and the number of buckets in the hash table. What is the proposed fix? |
I think @jamesroutley is suggesting to use a smaller prime for |
add a new function: int floor_mod(const int mod_num, const int check_num) {
return check_num % mod_num == 0 ? check_num - 1 : check_num;
} usage and fix the problem: const int aIndex = hashing(key, HT_PRIME_CONST_1, bucket_size);
const int bIndex = hashing(key, HT_PRIME_CONST_2, bucket_size);
const int mod_index = floor_mod(bucket_size, (bIndex + 1));
return (aIndex + attempt_i * mod_index) % bucket_size; |
hash_b(string) + 1 will never be 0, but it may end up having the same effect if hash_b(string) is (num_buckets-1). Then no matter what i is, the final result will be the same as hash_a(string) % num_buckets, effectively resulting in the same DDOS explained before.
The text was updated successfully, but these errors were encountered: