Q1: Should the server queue up user commands and execute them in order or should it only execute the newest command recieved? Assuming it does queue them, how fast should the server execute them (e.g. should it execute them all in one tic or spread execution out over multiple tics)?
Depends on how you implement your world.
Generally the server doesn't get behind, and if there is a queue it is very short. In many fast-paced games the server operates with a small window of time. It examines the time stamp of an event, and if the event is within the time window it inserts it within the simulation, often seen as "rewinding" time. If the time stamp is older than the window it is expired and discarded. If the time stamp is newer than the window then it is in the future so the person is a cheater.
The server generally lives in the future relative to what the clients see on screen. What the player sees as "now" was actually around 10, 20, or even 100+ milliseconds in the past as far as the server is concerned. The article describes how it works around this in part 4. The "rewinding" aspect kicks in and the simulation is processed as though the event from the past were part of the timeline.
Fortunately for most games simulation processing is extremely fast, it is the rendering and similar tasks that consume the most time. Assuming the developers keep all the simulation data around in a sane format it can be rewound and replayed quite easily. If the developers don't, it is much harder.
Q2: If the server runs out of user commands for a client (e.g. due to lag), then should player logic continue to execute with the last user command recieved or do nothing? My assumption is to do nothing. This question comes from the idea that the buttons last pressed might still be pressed during the next tic.
If it is within the server's window of available time you can insert it. If it is outside the window of time you dump it.
Q3: Should the client send its entire history of user commands that have not been acknoledged per-tic or should it only send the very latest user command per-tic. This assumes when a user command is acknoledged, then it and all older entries before it will be removed from the clients history.
There are many common patterns.
In UDP, a common pattern is to repeat until acknowledged. It looks similar to TCP's sliding windows except it resends the data every time instead of when So packets transmitting events look like this:
--> {#1}
--> {#1}{#2}
--> {#1}{#2}{#3}
--> {#1}{#2}{#3}{#4}
<-- {Ack #3}
--> {#4}{#5}
--> {#4}{#5}{#6}
<-- {Ack #5}
--> {#6}{#7}
If your game is very chatty you may accumulate five or ten small items, in which case you may want to revise your protocol. In practice games usually have either nothing or a single item in the queue, occasionally getting two or three during busy times.
That isn't required, just a common pattern for UDP transmission. Other games use more of a TCP model of sliding windows, assuming that data went through properly but reserving them in a buffer until acknowledge in case retransmission is needed.
Generally modern networks work quite well and desktop boxes seldom have packet issues at UDP's layers. UDP can still have issues, it just is quite infrequent. One system may run for months with no issues, a second system may run reliably for hours with no issues, then have a few odd packets, then return to reliability. A third system may exhibit frequent instability. What is invisible to you is that the first one is talking between computers in the same corporate office building, the second is cross-country to a home computer, the third is someone on their laptop in a train using cellular wireless.
