[ENet-discuss] ENet performance (packet reuse/allocation, channel count...)

[Kevin Gadd]

Perfect. Being able to send the same packets multiple times will be a
godsend - glad that's possible. Probably wouldn't hurt to document that
somewhere. :)

I noticed the callbacks stuff in the new version of the library but didn't
notice that it was for allocation. Makes sense. Is there any way to turn the
callbacks on and off dynamically so that I can only use them when I'm
creating a packet from an existing memory buffer?

Thanks!
-kg

On 5/1/06, Lee Salzman <lsalzman1 at cox.net> wrote:
>
> Unless there is some bug I am not aware of, packets are reference
> counted and can be sent as many times as you want before the call to
> enet_host_service. Just do not modify the contents of the packet.
>
> You can specify a custom allocator by using the
> enet_initialize_with_callbacks() function instead of enet_initialize().
>
> I would try not to create an excessive number of channels, although a
> small number shouldn't hurt. There are some parts of ENet that could be
> more scalable than they are.
>
> Lee
>
> Kevin Gadd wrote:
> > Hey all,
> >
> > I'm working on an experimental small-scale multiplayer engine that is
> > designed for fairly large (compared to a typical use of ENet, anyway)
> > client counts. Because of this, I'm going to be sending and recieving a
> > LOT of data (and packets). Currently, sending a packet to multiple peers
> > requires creating a copy of the packet for each individual peer (unless
> > I'm sending it to all my peers, and I can broadcast it). The expense of
> > all these packet allocations (and data copies) is somewhat significant.
> > In general, having to create a new packet every time I send data is
> > complicating my network code considerably. My previous performance tests
> > of sending large amounts of data via enet were not particularly
> > encouraging - it worked, mostly, but the library definitely struggled
> > under heavy load, and completely failed if I queued too many packets at
> > once (due to what, I assume, is a fixed-size queue somewhere). The limit
> > on how many packets I could queue at once meant I either had to batch
> > packets in small amounts and service my host repeatedly, or send very
> > large packets. Large packets meant lots of big copies and allocations,
> > which wasn't much of an improvement either.
> >
> > Is there a way I could reuse a single packet for multiple sends, or even
> > better, create a packet without allocating a new data block for it
> > (ideally, I'd be using an existing block of memory instead)? There
> > doesn't seem to be any straightforward way of doing the latter
> > currently, but it seems like in theory the former could work with the
> > current ENet api at least (though none of the documentation actually
> > says whether or not a single packet can be sent multiple times - the
> > tutorial just says enet handles deallocating it automatically).
> >
> > If there isn't any good way of solving this problem with the current
> > API, I'd like to extend ENet to support setting up a custom allocator,
> > or at least passing pre-existing data when creating a packet. Either
> > option would allow me to easily pin my existing data in memory and pass
> > it to enet, saving a considerable number of allocations and copies. If
> > this ends up being the best route to take, any suggestions on how to
> > design these changes would be appreciated - if I go to the trouble of
> > doing this, I'd like to make sure and at least make the changes in a
> > manner that allows them to be integrated into the official codebase.
> >
> > On a related note, I was also wondering if there is any significant
> > performance/memory usage impact involved in setting up a connection with
> > lots of channels. Ideally I can just set up all my connections with a
> > good number of channels (16, 32, 64, whatever), and start communicating
> > on different channels as needed without breaking client/server
> > compatibility. But if unused channels have a significant impact on
> > performance I'll have to wait until I really need the channels before I
> > start using them.
> >
> > In the meanwhile I'm going to keep mucking around and see what I come up
> > with, but I wanted to get some feedback from people that have more
> > experience with enet than I do.
> >
> > Thanks,
> > -kg
> >
>
> _______________________________________________
> 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/20060501/4cb5486d/attachment.htm