Now most of big website like Google mail, Twitter, Facebook have a feature that assesses password strength (check number of digit, alphabet, special characters, or check the similarity over already hacked passwords) for a guest while he is in a registration, but where should the assessment be processed at client side or at server side and then the server sends the assessment result to the client. In case the answer is at server side, does the server assess the password's strength over the plain text form or encrypted form of the password.
Password strength, in this context, is a meaningless concept. The strength of the password, in most cases, isn't an intrinsic property of the password itself. That input validation logic in registration forms merely checks the password against a certain criteria: Does it have a number? Does it have a special character? Is it longer than 8 characters? etc.
Such checks can be done in the client's browser or on the server. Enforcing those conditions, however, can only be done on the server as the user can simply bypass those client-side restrictions. Those checks are done in the user's browser because it's much faster to do them there; they're just indicators for the user. Once the password is submitted to the server, it must be checked against those conditions.
Side note: I'm not a big fan of restrictive "password strength" conditions and I don't recommend them. However, I do see the benefit of checking for a minimum length and making sure that the password doesn't exist in a dictionary or wordlist.
Either is acceptable
A few considerations:
In fact, rather than a password strength checker, I favour having a password strength advisor. As the user types their password, an indicator says "weak... medium... strong". They are not forbidden from using a weak password; they are just warned.
That being said, in the World Wide Web passwords are almost always sent to the server in plaintext, but ideally over HTTPS so that the SSL wrapper provides security. They're either in plaintext in the form GET or POST, or they're encoded (not encrypted) in the HTTP Basic Auth header. Why? Key management.
The client has no way to key to encrypt the password that the server shares. Setting one up would either require distributing secret keys to N+1 clients and maintaining secrecy... or setting up a public key system. And once you've set up a public key system, you just kick yourself and say "Why didn't I just trust the SSL to begin with?"
Now, here's some outliers to consider:
It's possible for a server and client to perform digest authentication. In short, the server sends a random string, the client hashes the password and mashes it up with that random string and sends it back. The server needs to have a plaintext copy of the correct password on its side; it performs the same hash+mash process and compares. This is harder for an attacker to grab the password on the wire, but usually requires that the server know the plaintext password (as opposed to a hashed version).
If you need the password strength policy to be enforced, perhaps as part of one regulation or another, the enforcement has to be done on the server side. Any client-side checking can be (relatively) trivially bypassed.