You misunderstand. The default behavior of ENet, if an unreliable packet is
larger than MTU, is to fragment it and reassemble it on the other side
transparently, but it is marked reliable to do this, despite the original
packet being unreliable. This behavior can be overridden to send the fragments
unreliably too, but you have to explicitly pass in the unreliable fragment flag
to make it do that, otherwise you get the reliable fragmentation.
On 10/02/2012 04:46 PM, Stefan Lundmark wrote:
I was under the impression ENet handled packets larger than the MTU on both
reliable and unreliable.
Just to make sure I understand: So this is only the case for reliable packets?
Thanks,
Stefan
On 2012-10-02 15:25, Lee Salzman wrote:
Sending a lot of little ENet packets (10-20 bytes) is going to consume a lot
more than that per packet in terms of internal ENet protocol headers. To save
on header overhead, you should batch stuff together into one bigger packet on
your end, especially if it is reliable. If it is unreliable, you should still
batch, but make sure you're not going over the MTU, and if so, either using
unreliable fragment, or making sure to split stuff up so to not accidentally
get packets marked reliable that you don't want.
On Tue, Oct 2, 2012 at 4:20 PM, Lucas Beyer <[email protected]
<mailto:[email protected]>> wrote:
Hello,
My gameserver runs in ticks (0.1-0.01s). Each tick, events happen,
which need to be reliably sent to the clients.
Is it better to
a) each tick, send one big message containing all events which
happened during the tick or
b) send each event (~10-20 bytes) as a separate message during the tick?
As I understood, messages are only really sent through the wire during
a call to enet_host_service, right? I call this between two ticks, so
in both cases a) and b) would send the message(s) at the end of the
tick.
I know the best answer is "implement both then measure" but I was
wondering if, in enet and considering they all need to be reliable
messages, there are reasons why one might be inherently better than
the other. "big" is around 10-20 kilobytes.
--
Best regards, Lucas
http://arkana-fts.org
_______________________________________________
ENet-discuss mailing list
[email protected] <mailto:[email protected]>
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
