The How-part is less important, the efficient-way is cardinal:
Let's jump a few months forward. Your game has several million downloads and your server part has to cope with a huge herd of keen gamers online 24/7/365.
This landscape will help to show the core importance of a distributed-system design properties and a pain any low-latency controlled software ( the gaming being out of question such case ) will put on table.
Why latency? A good game design strives to create and maintain a realistic user-experience. Let's take a shooting example - if player A achieves to destroy target X, then target Y and finally target Z within a last few moments, but a player C has shot player A even "before" the player A started to shoot, while due to a poor ( un-equal ) latency of end-to-end game connection delays, the "bullets" from C reached server "late" and got distributed "after" targets X, Y and Z were confirmed to be destroyed - will you kill A and respawn X, Y, Z or will you leave X, Y, Z exploded and let A die later, under blue sky without a warning or would you let him/her go ahead as if not having been already killed from player C? - your platform gaming-experience will become very unfair for not just one of the players C, X, Y, Z involved. Users hate this. Flames will follow very fast.
Latency variability in time ( a latency jitter ) is another problem -- Some remarkable platforms, IL2-Sturmovik was such case to name some, experienced "jumping" in-game objects due to this type of un-handled latency-related distributed game-engine controls. The gaming community soon realised this handicap and black-MOD-ers spawned many MODs, where this weakness was explited to an unfair benefit to (cheating) players, who benefited from blocking packets, that distributed in-game reality updates and using this hack their planes become stealth ( un-hit-able by attackers' bullets ) and sometimes even UFO-ed in 3D-scene, due to late/very-late arrivals of some plane's in-game 3D-coordinates' updates.
If you realise, that 0.1 sec is about not going above 10 FPS of in-game reality updates, while contemporary in-game reality strives to have some 50 - 80 - 120 FPS for High-Fidelity user-experience, the pain you will face on this grows even higher.
So, how to attack the issue?
ZeroMQ is a wonderfull framework for distributed systems. Mastering this tool will out of question help you learn a lot about non-blocking, about efficient end-to-end messaging ( updates of any kind, controls, signalling ) and you will also learn, how to reduce the network traffic ( imagine 10 gamers v/s 1.000 gamers v/s 100.000 gamers network-segment loads ).
ZeroMQ will also help you to include work-load balancing among multiple server-side machines, thus increasing your back-end capabilities as your player counts increase - ZeroMQ supports almost linear scalability, that is worth some pain during one's learning curve, isn't it?
The server side has typically many duties to handle concurrently. An over- simplified core-loop of the in-game distributed messaging framework event-processing engine looks similar to this:
... # setup
while True: # ||||||||||||||||||||||| DANGER-ZONE vvvvvvvvvvvvvvv FAST
anInterruptSegmentedCDOWN = 60 * 100 # 100 * 10[ms] dual-poll-overhead -> aMinuteCOUNTER
#-----------------------------------------------------------
while anInterruptSegmentedCDOWN > 0: # CDOWN-loop-[aMinuteCOUNTER ~ 1 minute with 6000-loops 10 [ms] each ]-----------100x [sec] 6000x [min]
anInterruptSegmentedCDOWN -= 1
#-------------------------------# SIGsPORT >>> AVOID WARM-UP delay at the end of the story, where SIG_EXIT needs to be delivered IMMEDIATELY >>> https://stackoverflow.com/a/33435244/3666197
try: #----------.send()--------# NOBLOCK-# .send() aMSG, may throw an EXC
...
except:
...
finally:
...
#-------------------------------# CtrlPORT
if ( 0 != aCtrlSOCKET.poll( 0 ) ): # IF .poll( 1 ) - a fast .poll()
...
#-------------------------------# RecvPORT
if ( 0 == aRecvSOCKET.poll( 9 ) ): # IF !.poll( 9 ) - relax & wait for aMsg ... 10 [ms] REDUCED waiting, due to a need to keep a SIGsPORT heart-beat about 100 ms so as to avoid IDLE/WarmUp on socket once SIG_EXIT is to be delivered
...
else: # ELSE = [MSG] IS HERE,
# GO GET THE JOB DONE ~~~~~~~ AI-ZONE <<<< [MSG]
... # ~~~~~~~ HERE
# # THE MAGICS
# # HAPPEN
continue
# |||||||||||||||||||||||||||||||||||||||||| DANGER-ZONE ^^^^^^^^^^^^^^^ FAST
The best next step?
You might be interested in more details -- What is a difference between WebSockets and ZeroMQ
However for your further questions you might want to see a bigger picture on this subject >>> with more arguments, a simple signalling-plane / messaging-plane illustration and a direct link to a must-read book from Pieter HINTJENS.
