[ENet-discuss] New idea for packet sending

[Benny Kramek]

Hi, I've been using ENet in an open source game called DIE 
http://die.sf.net and so far everything has been working awesome. Thanks 
for such a great library =)

I've decided to recode the game engine from scratch because a lot of 
things were getting too messy. So I've been thinking about how to do the 
new networking structrue, and I came up with an idea for sending network 
packets that is sort of a mixture between reliable and unreliable 
packets. I don't really know anything about low level networking or 
about UDP, so I thought that I would ask here if anyone has any comments 
on my idea.

Explaining it is a little hard, so I'll try with an example:
Imagine a FPS game where the server is controlling an AI bot and a 
client is watching the bot move around. One approach to do this is for 
the server to send to the client at a regular interval the position of 
the bot, using unreliable sequenced packets. It doesn't matter if a 
packet gets dropped, because the position will be updated by the time it 
could have been resent. But when the health of the bot changes, then the 
server must send a reliable packet that contains the new value of the 
health. The health doesn't change often, so it's important for the 
packet to arrive when it's value changes.

The idea I have, is to unify these 2 methods of sending packets. My idea 
is only useful when there are 2 machines on the network, and one machine 
needs to update the other machine on a changing value. This is sort of 
how it works, the details I'm still not sure about:

Let's say a server needs to update a client about the position and 
health of a bot:

The server has a "network update tick" that runs at a constant rate. The 
server has a list of values that need to be "replicated" to the 
client(bot-position and bot-health). During the network update tick, the 
server checks to see which values changed since the last network update 
tick. It sends the updated values to the client using an unreliable 
sequenced packet. If a value hasn't changed for 1 tick, then the server 
sends out an unreliable packet that represents a request for the client 
to confirm the arrival of the updated value. The server keeps track for 
each value(position and health) how many network update ticks have 
passed since the value was changed, as long as the confirmation packet 
has not yet been recieved from the client. The server will resend the 
value if a threshhold is reached.

So what would happen is, the position value would be changed very often, 
so the server wouldn't have to send out confirmation requests. On the 
other hand: If the position would stay still for long enough to send out 
a confirmation request, but then the position would change again before 
the confirmation request was recieved, then the server would forget 
about the old value + the needed confirmation, and the server would just 
continue on and send the new value.

The system basicly always sends reliable packets - but it cancels ones 
that are obsolete.

The nice thing about the system, is that values don't needs to be set to 
be reliable or unreliable. If the bot stays still then his final 
position will be updated reliably, and then no more packets will be 
sent. If the bot stands on lava and his health is slowly constantly 
decreasing, then the packets will arrive unreliablly and thus reduce 
latency. The system will always make sure that the recieving machine 
will always have the most up-to-date values.

A variation of the approach, is to not have the server send a special 
packet confirmation request, but instead to have the client confirm all 
of the packets. But this might be hard on bandwidth.

Am I making any sense at all? Does the idea make sense, will it work? 
Also, using a system like this on top of ENet might be difficult since 
it requires some low level control over packet delivery. Any other thoughts?

Like I said, I really don't know anything about network programming so 
the idea could just be totally wrong.

Thanks

-- 
Benny Kramek
   http://benny.kramekweb.com
   benny at kramekweb.com