Hey all,<br><br>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.
<br><br>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).
<br><br>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.
<br><br>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.<br><br>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.
<br>
<br>Thanks,<br>-kg<br>