1. Yes identify your clients. Usually a server has more than one game at a time. So besides "not mirroring client 1 back to itself", it's also about "not sending client 3 which is in another game" back to clients 1 and 2.

2. You can use asynchronous io. Look up TCP IO selector on google. It can handle many connections on a single thread. The problem is that It is more difficult then using threads, so if you only have less then 10 connections at a time, don't think about it and keep using threads.

3. Some people like to use UDP instead of TCP for multiplayer. It is much faster than TCP, and you can also broadcast to more than one player at a time. The problem is UDP packets can arrive out of order, so you need to re-order them. If you are using TCP, don't worry about it. TCP is basically a high level protocol over UDP that includes ordering and error handling. If you are making a realtime game, I would turn on TCP_NODELAY to prevent TCP from delaying transmission of your data. These delays can reach several 100s of milliseconds.

For Question 1 --

a) Just because client 1 sends a command to move forward doesnt mean it gets received in time to move forward in that cycle/turn of the servers processing. That might come later in time (next turn...). Of course, if the turn around period is long the client may visibly move itself anyway and once confirmation from the server comes in then it can procede (or if some unexpected thing happened it would have to undo/adjust what it originally projected)

b) depending on what visibility rules your game mechanics use, the move data for client 1 may NOT need to be sent to client 2 if it is calculaterd (at the server) to be out of visibility to client 2. On big worlds that is done alot.