I favor using a producer-consumer design pattern for problems such as these.

The networking thread reads incoming packets/data/whathaveyou, deserializes them appropriately, and stores them in a queue. This is the 'producer'. Each game loop, the game logic empties this queue and performs the appropriate game logic. This is the 'consumer'. The two threads never interact directly.

You still have a client-server architecture whether you're connecting via LAN or not, and the same set of challenges as far as how the two should communicate still apply. You have a lot more reliability and less lag over a LAN but since this is more of a discussion about how servers keep clients updated on game state, I don't see how LAN makes any difference.

You should really read the source multiplayer networking link I posted. You'll probably need to read it over a dozen times to fully get all the concepts but it's all layed out quite nicely in there.

I'm not sure I totally understand what you mean by 'sever delta', but if you go back to the outline I gave above, you'll remember that the server is sending the client snapshots of world data. This is typically done every 50 ms. So imagine you're a client and you've just received a snapshot. It contains two things: world data and a timestamp of the server at the time it was created. You now have a snapshot of the world as it was at the time given in the snapshot.  

For now I would just assume that both client and server are synced on the same clock. This is absolutely untrue but just getting started it won't be helpful trying to also work in clock syncing. And for now since you're developing locally you can put off worrying about ping, since it will be close to 0. These two things you will later need to work into your system as ping and clock deltas obviously do exist, but for the time being assume the server time of your snapshot is also local client time.



Just starting out to make sure everything is working you could immediately update your local client version of the world to this snapshot. It will be synced but since you're only receiving updates every 50ms, it'll be very, very choppy. How do we solve this? We need a way to get the snapshot of the future state. This is done by moving the client view of the world back in time. If we did so by say 50ms (we'll call this view lerp) then we'd usually have one snapshot to move forward to (assuming the snapshot packet isn't delayed or dropped on its way to us). So now you have version of the game world as it will be 0-50 ms from now. Every client update loop you can calculate how close you are to that upcoming snapshot and move everything towards their final authoritative positions (this is called interpolation).  

I think that should be enough to get you started, but there is obviously more to it. Most games move their view lerp back 100ms in case a snapshot is dropped, they'll always have another one to move forward to. Again, read that link, it has all these details and much more.

The answer to this question is highly dependent what you desire as far as gameplay. There are pros and cons to both systems.

Are your clients constantly moving around?
Will other connected clients need to see them in their exact positions or can they be fudged a little? (think WoW where everyone sees each other in slightly different positions)

In an fast paced game (think first person shooter), the client should be sending only their inputs to the server. The server receives the inputs, validates them, applies them to its version of the game world, and ultimately sends the client back a snapshot that contains their changes. The client is never trusted to determine its own position (or health, money, etc.). Pros to this system is it's not possible to cheat the server by telling it impossible things. The server will determine the outcome of all actions so they are always correct. Cons are increased communication necessary between client and server and having to implement more client side prediction and recovery code to make inputs appear instantaneous. It simply wouldn't do for clients to wait 150ms round trip before their actions took effect, so you predict what will happen on the client side and make corrections based on what the server tells you later.

If your game is twitch based and your players are taking aim at each other, then it makes sense to implement a snapshot based system so everyone is seeing the same thing. If your game is more target based, like you select someone and then cast a spell but never have to aim the spell, you might be able to get away with sending just positions (and doing some checks for impossibility). This is what many MMOs do because it allows them to lower the amount of traffic to the server for basic movements.

Edit: As far as collision detection goes, this is just another thing that the server can do on its end and inform the clients of. Here's sort of an outline of what a server might do in a FPS:

every 15 millseconds:
1. check network for updates clients have sent me, store the unprocessed input for consumption
2. for each player in the world, apply any unprocessed input gathered in step 1
3. run a simulation step and update the game world based on the time since last update (ex. move any projectiles forward)
4. check all game objects for any collisions, perform appropriate actions (ex. move players back so they aren't colliding, apply damage for any projectile hits)
5. clean up the world, removing dead entities
We have a world that is completely up to date. We could send a snapshot of this world to all players, but it's usually not necessary to do so every tick.
6. if it's time to send a snapshot, create one and send it all connected clients

More information: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking