I am familiar with Full client side hit detection and full server side hit detection.

However I'm not very clear on client side hit detection with server validation.

What are the different strategies server validation uses to verify the client's claim? I'm more interested to learn about some details of implementation of it, rather than purely theoretical explanation.

When the client says it hit, the server also performs the hit test. This potentially saves effort on the server since it doesn't need to validate all the potential hits, or all the potential misses, it only needs to do the test if the client makes the claim.

The client performs the hit test but nobody else sees it unless the server's test is in agreement. The whole reason for doing this is to allow client-side effects to be generated that depict the damage being inflicted to give the game a more responsive feel. If there are discrepancies between the client and server simulations then there would be cases where a player would see all the effects of landing a hit, or missing one, and then have the server do the opposite. The added responsiveness would be at the cost of potentially frustrating players at times.

EDIT: alternatively, you could make the client perform the hit test and then the server could execute a set a heuristic checks to test that the hit is likely valid, without being the authority over the exact details. This would be ideal.

heuristic check

That technically means using approximation and guesses like if the player had ammo , if he was actually near the enemy or could see the enemy?

or does it means something else altogether

Got this on my todo list for my current project and the model I'm thinking about looks something like this:

player_a is on frame 400 locally.

the server is processing player_a's frame 395

player_a is replaying player_b's frame 392

player_b is on frame 402 locally

the server is processing player_b's frame 395

player_b is replaying player_a's frame 393

player_a shoots at player_b and its input, rotation, etc are passed to the server as part of his frame 400 data along with information about its assumption that it got a hit-confirm against player_b @ 392

When the server comes to process this frame it checks the hit against a simulation of player_a@400 against player_b@392 and if it scores the hit it corrects player_b with the hit if it misses it corrects player_a with a negation of the hit. This comparing hit's at different frames removes the need to lead targets, etc.

I guess that raises questions like:

• How far in the past is still "legit" (should player_a's lag give it a larger window to hit player_b and how goofy will it look if player_a shoots player_b half a second after it walks past player_b and round a corner)
• If player_b activates a shield at frame 398 should it's negation at what is "before" from the servers perspective but "after" from player_a's perspective block player_a's shot at frame 400?

This is a great video on the subject:

And from what they talk about in that video my (naive) understanding is it works like the above and recent tweaks, talked about @9:42 (exceptions to "favour the shooter") mean in the example where player_b pops a shield that the shield will mitigate even if the hit-test is in the past(in Overwatch's case the server must have already processed the shield activation, meaning lag will hurt your mitigation perhaps?).

I've yet to do this on my own project so this is all speculative, and would also love to hear from someone in the know :)

This would be ideal.

I don't think heuristic server-side checks are ideal, because they open up the window for cheating.
In the earlier days of FPS games over modems/DSL, cheating players would have a network hub with a switch, and they'd turn off the hub, get 2-3 seconds of no other player moving on the screen, would shoot those players, and then turn the hub back on.
The result would be that the server would see a stream of "I shot player X at location Y at time T" and those requests would check out based on the backwards-calculated server state.
Loosening the rules to allow "probably near enough" hits would allow clients to do things like increase the size of hit boxes and get a much higher hit ratio.

To me a guess on the server side sounds scary. For authoritative servers based on what I've seen you never leave anything to chance and always assume the client is untrustworthy. Of course that may depend on the kind of application you are developing. The client is supposed to be a dumb terminal so to speak of what's going on in the server. So the player "sees" he is within range to hit something, the client sends a hit request to the server, the server may use a physics engine to determine whether any collisions occurred and respond to the client accordingly. The response need not be direct. For example once the collision was detected server side, the reaction to that may be to update the health of the thing that got hit. The client will receive an update of that entity's health eventually (sarcasm) through some other response system.

Note: sometimes it is "safe" to make guesses and assume the client is sending valid data. Why? Because it wont affect the server negatively. For example the server doesn't care if a client is modified so its controls send "move left" when it actually was supposed to send "move right". The player will be very unhappy, but its not the server's fault he screwed with his client.