[ENet-discuss] Shooter Game

[Lee Salzman]

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 <lsalzman1 at cox.net> 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  )  ??
>
>