[ENet-discuss] Questioning a server without connecting to it
lsalzman at gmail.com
Fri May 25 21:13:00 PDT 2012
Which is why 60Hz is basically an insane network rate. You're still
drowning in headers no matter how small you make things. Really, you don't
need 60Hz. For objects with predictable trajectories you don't really need
more than 20-30Hz. The changes in trajectory don't need to be sent at any
particularly rate, and thus are sent out immediately, there doesn't have to
be a delay involved.
On Fri, May 25, 2012 at 9:04 PM, Emmanuel Rivoire <manu.n02 at laposte.net>wrote:
> At 22:48 25/05/2012, you 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
> My game is mainly played over Internet, and some people still have only
> 128kbps of upload, and in real it usually can handle less than that. But
> even with that the transfer time for 10 bytes isn't too big, the issue
> isn't really here.
> But Internet is a big place with congestion, stalling & packet loss, and
> to avoid all of that, my guess is it's better to have the smallest packets
> possible, so I see no reason to send unneeded bytes, especially when it's
> not so hard to remove them.
> Another issue is that some people have capped download/upload amount per
> month. So any saved bandwidth is good for them.
> ENet-discuss mailing list
> ENet-discuss at cubik.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ENet-discuss