[ENet-discuss] New idea for packet sending
benny at kramekweb.com
Sat Feb 21 01:24:02 PST 2004
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.
benny at kramekweb.com
More information about the ENet-discuss