[ENet-discuss] 1 big or many small messages?

[Lucas Beyer]

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

[Lee Salzman]

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 <pompei2 at gmail.com> 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
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20121002/b5d8e2b2/attachment.html>

[Lucas Beyer]

Thank you, this is exactly the kind of answer I needed :)

--
Best regards, Lucas
http://arkana-fts.org

[Stefan Lundmark]

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 <pompei2 at gmail.com
> <mailto:pompei2 at gmail.com>> 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
> ENet-discuss at cubik.org <mailto:ENet-discuss at cubik.org>
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20121002/7e579cf6/attachment.html>

[Lee Salzman]

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 <pompei2 at gmail.com <mailto:pompei2 at gmail.com>> 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
>> ENet-discuss at cubik.org <mailto:ENet-discuss at cubik.org>
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>
>>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

[hawkhawk-eagle]

ENET_PROTOCOL_MAXIMUM_PEER_ID howto change big than 0xffff i want to change it to 0x7fff. and client used 0xfff.it can not connect why?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20121003/c0b807e7/attachment.html>

[hawkhawk-eagle]

From: hawktjj at hotmail.com
To: enet-discuss at cubik.org
Date: Wed, 3 Oct 2012 04:34:00 +0000
Subject: [ENet-discuss] ENET_PROTOCOL_MAXIMUM_PEER_ID howto change big than 0xfff i want to change it to 0x7fff. and client used 0xfff.it can not connect why?




ENET_PROTOCOL_MAXIMUM_PEER_ID howto change big than 0xfff i want to change it to 0x7fff. and client used 0xfff.it can not connect why?




_______________________________________________ ENet-discuss mailing list ENet-discuss at cubik.org http://lists.cubik.org/mailman/listinfo/enet-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20121003/3c09397f/attachment.html>

[Lee Salzman]

You can't raise this value any higher, sorry.

On 10/03/2012 07:34 AM, hawkhawk-eagle wrote:
> ENET_PROTOCOL_MAXIMUM_PEER_ID howto change big than 0xffff i want to change it to 0x7fff. and client used 0xfff.it can not connect why?
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

[hawkhawk-eagle]

why can not ? i have a early version is 0x7fff,why new version can not do that? .i think should change code.now



> Date: Wed, 3 Oct 2012 03:56:50 +0300
> From: lsalzman at gmail.com
> To: enet-discuss at cubik.org
> Subject: Re: [ENet-discuss] ENET_PROTOCOL_MAXIMUM_PEER_ID howto change big than 0xffff i want to change it to 0x7fff. and client used 0xfff.it can not connect why?
>
> You can't raise this value any higher, sorry.
>
> On 10/03/2012 07:34 AM, hawkhawk-eagle wrote:
> > ENET_PROTOCOL_MAXIMUM_PEER_ID howto change big than 0xffff i want to change it to 0x7fff. and client used 0xfff.it can not connect why?
> >
> >
> >
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20121004/db055d24/attachment.html>