[ENet-discuss] Questioning a server without connecting to it

[Chris Jurney]

Saving a few bytes is critical if you're near the client's bandwidth
limit.  Lots of residential connections are very slow upstream
(64kbit-128kbit is common), so if you're sending every frame or even
every other frame, every byte counts.  That pattern is very common for
a deterministic sim game, since you can't function without getting the
stream, so none of the bytes are droppable, and your input latency is
determined by the connection latency and variance.

60hz is insanely high for a network rate.  You're burning 13.44kbit of
your upstream just on UDP per stream (per user in a deterministic
game).  Add in enet and your own header, and that's a lot of nothing
going through a narrow pipe.  If you have a drop and need to
retransmit, the bandwidth spike from that is going to potentially take
out your connection.

On Fri, May 25, 2012 at 8:48 AM, Jay Sprenkle <jsprenkle at gmail.com> wrote:
> Perhaps I am wrong, but I believed the overhead for a few bytes within a
> packet was almost zero.
>
> Here's my logic:
>
> If the packet is smaller than the 1500 byte maximum packet size then the
> packet will be enlarged and no additional packets will be sent.
> 10 bytes / 10 megabit per second = 1 microsecond of overhead to serialize
> the bytes.
> A very good network latency is 2 milliseconds.
> 1 microsecond / 2 milliseconds =  0.05% additional overhead in transmission
> time
>
> The only additional overhead I see in the game program is the time to
> serialize/deserialize the additional bytes.
> I can't estimate those since I don't know how your code does this.
>
> If this is wrong, or overly simplistic, I'd be happy to learn where it's
> wrong.
>
> Jay
>
>
> On Fri, May 25, 2012 at 9:51 AM, Emmanuel Rivoire <manu.n02 at laposte.net>
> wrote:
>>
>> At 19:55 25/05/2012, you wrote:
>>>
>>> In that case it sounds like the optimization chances are more at your
>>> end, trying to aggregrate information. If overhead is larger than the data,
>>> you're probably sending too little data. ;-)
>>
>>
>> Damn, I sweat my brain off to get the smallest data needed to go over the
>> network, and got blamed for it..! ;-)
>>
>> More seriously, I have to send 60 packets / second, coz sending only 30
>> packets/s would mean to add 16.67ms of latency and that'd be bad for my game
>> : it's a tennis game, it's very latency dependant ; for example, the ball
>> can travel almost 1 meter during 16.67ms on the start of the service.
>> I did a lot of things to fight back the latency at the game level and
>> network level, but the 1st thing is to have the smallest packet possible
>> sent 60 times / second, thus my concerns about all optimizations.
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
>
> --
> ---
> "There's a zombie outbreak!  Oh, no, wait a second...  It's just a bunch of
> kids texting."
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>