curious results from md5

Unfortunately, we return the raw result of the MD5. I'm not sure what we would ever use that for... Instead, you simply need to b64 encode it. Try this instead:

set clienthash [b64encode [md5 [IP::client_addr]]]

Does that mean that the -hex argument isn't valid?

when CLIENT_ACCEPTED {
  set client [IP::client_addr]
  set clienthash [md5 -hex [IP::client_addr] ]
  log "the client is: $client the clienthash is: $clienthash "
}

*Edit*: I mean, I've tested the syntax, and it doesn't compile, I understand that. I'm just curious if there's a reason we haven't implemented it as an option.

Colin

Because we already had the b64encode command and it's not a performance improvement to do it within the md5 command...

 

 

(Often times, the reason a switch is in a command is because it can be implemented with much better performance, eg: the switch -nocase for string/switch commands saves copying the object into a lowercase form).

Ya - but it would be really handy to be able to do mod and other match on the md5 hashes for persistence and pool selection. The b64encode outputs alpha-numeric, so you are hobbled in what you could do with the string.

Then perhaps you want to binary scan it into a variable...

binary scan [md5 [IP::client_addr]] i4 md5ary

This will return the MD5 hash into 4 32-bit values as a list in md5ary. If you are only interested in using, say the first 4 bytes of the hash, then you could do:

binary scan [md5 [IP::client_addr]] ii3 md5var junk

This will put the first 4 bytes into the variable md5var and the rest in junk. Note: this would also be the equivalent of [lindex 0 md5ary] from the first example.

Good luck.

Has the behaviour of the md5 command changed in 9.4? In 9.2 I am seeing the broken raw strings as expected above. However there is an article series referring to md5[URI]%server persistence - and I don't see how this would work if the md5 command does not return an integer....

 

 

 

Confused...

 

 

Andrew

Hrm. It's possible that the "Typical Hash iRule" article originally had "crc32" instead of "md5", which should work fine. crc32 has bad properties for using it in Election Hash iRules, though. I'll poke deb to correct that article if she doesn't see this instead...

 

 

The Election Hash iRule you point out does take the IP into account, but it's a bit non-obvious. The $N variable contains the IP:port of each active member, and the MD5 is taken of "$N[HTTP::uri]", so it does take it into account. It is easy to miss the $N, though.

what was the final word regarding md5 in the Election Hash iRule? should md5 be working? was it meant to be crc32? Also, what are the 'bad properties' for using crc32 in Election Hash iRules?

It was meant to be md5, it just needs/needed the output converted to a numeric value.

 

 

crc32 works pretty well as a hash if all you need is a yes/no (i.e. this does/doesn't match) answer. This iRule, though, needs to numerically compare different values (i.e. less than or greater than, not just is or isn't equal), and for that crc32 will give uneven distribution. md5 is the fastest primitive iRules currently has for getting evenly distributed hashes.

Spark called it. crc32 is a cheaper operation than MD5, roughly %40 less CPU if I remember correctly. That makes the election hash iRule scale much better. But the downside to crc32 is that it often results in collisions. Practically speaking, this means that you will get an uneven distribution. If you have a bunch servers, some will get as much as %80 more than others even after a normalization of millions of queries. MD5 is meant to be cryptographically secure, hence very few collisions, which means for use as a load balancing algorithm, near perfect distribution of queries across servers.