The ENet header overhead is not bad, per se, but keep in mind if you are
not bulking stuff into packets, the overhead for my case would have been
N*(N-1)*30 packet headers, times whatever the size of the headers is.
That adds up quickly, especially if the headers are >= 20 bytes in size
all total, so that it would almost double (or worse) the bandwidth usage
the server was sending out!
Now, with respect to the second question, ISPs place much harsher caps
on upstream bandwidth than they do downstream, so upstream and
downstream bytes are not created equal. :)
Lee
Daniel Aquino wrote:
On Tue, Apr 14, 2009 at 10:52 PM, Lee Salzman <[email protected]> wrote:
Regardless, the biggest consumers of bandwidth and perhaps the most latency
sensitive data is position packets. In Cube 1/2, each position packet runs
about 20 bytes for each player (since it carries position, velocity, any
physics/animation state, etc), and it is sent unreliably at a fixed rate of
30 times a second. So you end up with a situation where the bandwidth usage
is (for N=number of players): N*(N-1)*20*30 bytes per second, since each
player must send its position to every other player.
Do you know how much the overhead there is for udp and enet headers?
If you went with a peer-peer scheme, the individual load
per peer would then only be (N-1)*20*30, but with greater overhead in
packets/headers, since they can't be bulked together into a single packet -
each update goes to a different client. But for each peer, this is all
upstream bandwidth.
What did you mean by this?
wouldn't the full upstream/downstream bandwidth be 2 * ( (N-1)*20*30 ) ??
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
