Well, the following is from a mail I recently sent to the SDL mailing list. It might be useful since it''s kept general. Note, I didn''t edit it from the original mail I sent. Anyway, here goes:

<---
This is what Quake and Half-Life use, and what I''ve implemented into my own
game (more or less). The protocol supports both reliable and unreliable data,
however it does not (for simplicity) allow data to arrive out of order, as
this would make the processing of commands unnecessarily complex anyway, and
the focus of the protocol is on unreliable data.

Every packet is prefixed with a short header, which includes a sequence (SEQ)
and an acknowledge (ACK) number. The highest two bits of these numbers are
reserved for other purposes.
Whenever a packet is sent, the SEQ is increased by one. The sent ACK is
always the last received sequence number. Unreliable data is just sent like
this.

Whenever there''s reliable data to send, a bit in the SEQ is set, indicating
reliable data. If the packet only contains part of a block of reliable data,
a second bit is also set.
After a packet with reliable data has been sent, the sender will not send
anymore packets with reliable data until the previous one is acknowledged.

On the recieving end, packets with illogical SEQ/ACK (this includes old SEQs)
are silently ignored. This will prevent most IP spoofing attacks.
If the packet doesn''t contain reliable data, its contents are simply
forwarded to the game logic.
If, on the other hand, it does contain reliable data, a number of things is
done:
First of all, the protocol keeps track of a "reliable sequence". The reliable
sequence is a single bit which is flipped whenever a reliable packet is
recieved. This reliable sequence is sent together with the ACK of a packet.
If a party receives a flipped reliable sequence bit, it knows that the
previous reliable packet has been received.

Secondly, if there is more reliable data to wait for (second bit in ACK is
set), the data is stored for later. Otherwise, all the reliable data received
up to now is forwarded to the game logic.

Unreliable packets are never resent (obviously)
Reliable packets are resent when we recieve an ACK greater than the original
SEQ number of the reliable packets without a change of the reliable sequence
bit.
Additionally, the protocol forces an empty packet every 500ms if no other
data is being sent.

Whenever a reliable packet is sent, the code looks for unreliable data that
might be put into the packet as well. The receiving game logic doesn''t have
to differentiate between reliable and unreliable data.

This protocol works pretty well for a shooter situation: both sides keep
sending data; the server sends frame updates at a constant rates, and the
client regularly sends movement commands. All these events are unreliable
(note that a client''s movement command also contains the two previous
movement commands as backup).
The occasional reliable data will eventually reach the other side without
impacting overall performance.

However, the maximum reliable data bandwidth is rather low, because no new
reliable data is sent until the previous block is acknowledged. So if you
really need lots of reliable data, you need to come up with something else.
--->

cu,
Prefect

Well, we''re talking about an FPS here, and in a typical FPS situation the server will send a world update every frame, and the client will send a movement command every frame. So that''s not an issue in an FPS.

If this is not the case, you should probably send "keepalive" packets, maybe two or three per seconds or so. That''s obviously only a hack...

cu,
Prefect

Every frame ??? I hope you limit your framerate to 20-30 then..