1. include shot event data in periodical update packet for 5 times in a row(if he will not receive any of these packets, then screw him, he probably has ping way > 100 or unstable connection).
2. instead of using sendTCP for each shot event, use sendUDP but 2 or 3 times, to reduce the chance of packet loss.
Always resending a fixed time doesn't handle it.
Why 5 for the periodical update?
Why "2 or 3" for sending an event?
If you chose five, what happens if a network disruption drops the next five packets and the sixth goes through? Alternatively, if it goes through perfectly the first time, why resend four unnecessary times? Same with events, why resend two or three times if once is enough, and why two or three if it might be the fourth time that goes through?
Why not 4? or 7? or 92? Or why not just 1, since the vast majority of time UDP gets through perfectly? Pulling numbers out of the ether does not help.
There is a known solution: Resend until acknowledged.
In the general case of networking the UDP packet will arrive quickly. Unless you have a particularly chatty interface, the data will arrive and the server will send a response back to you acknowledging it before your game needs to send another packet. Most games accumulate data for a short time window then send it off.
Effectively this pattern implements a sliding window similar to what you get in TCP, except you are not using TCP's stop-until-resent functionality, you always resend until the other side says they've got it.
If there is high latency or connectivity issue it may get sent multiple times before you hear back, but if the data is fairly small and you are on high speed networks the impact is minimal. While it is important to consider size a few bytes doesn't hurt if the game has requirements for megabit connections.
In the general case for well-designed protocols there will be a full round trip with acknowledgement of the data all the time.