[ENet-discuss] Multi-threading ENet the easy way...

Blair Holloway thynameisblair at chaosandcode.com
Thu Feb 4 14:39:40 PST 2010


The last game I worked on handled 16 players, fully connected (so each
machine had 15 active connections), and I think in heated dogfights we
peaked around 200 outbound packets per second. I'm reasonably sure
enet_host_service wasn't taking 20% of our frame time, or my lead would have
whacked me over the head with a cricket bat. :)

I'd be curious to see a more detailed profiling here - do you know where
Enet is spending its time?

Regards,

- Blair

On Fri, Feb 5, 2010 at 1:04 AM, Syed Setia Pernama <syedhs at yahoo.com> wrote:

> Hi,
>
> I have profiled my server which use enet and found that many enet functions
> are using quite substantial of cpu processing (~20%). I know probably many
> of you don't see enet as the bottleneck while profiling, but mine is a
> little different, it is a server which can send (and receive) 60
> packets/second to 5 clients. I know, i know that there are some past
> postings suggested that this is not the best way to do it (60hz), but as it
> is now it is running okay. But the more pressing issue now is to increase
> the performance so we decide to make full use of quad core via
> multi-threading technique.
>
> What I am thinking of the easy way to multi-thread enet is to specifically
> run this:-
>
> std::vector<std::pair<ENetPacket*,ENetPeer*>packets;
> while (enet_host_service (mHost, & event, 0) > 0) {
>   ...
>   switch (event.type) {
>     case ENET_EVENT_TYPE_RECEIVE:
>       packets.push_back(std::make_pair(event.packet, event.peer));
>  ....
> }
>
> on thread. The thread will be continuously run 'enet_host_service' function
> until the server shutdown.
>
> And the enet packet which is stored using 'packets' variable above, will be
> made available to main thread via another function -
>
> void getPackets(std::vector<std::pair<ENetPacket*,ENetPeer*>>& packets)
>
> Of course, this function will perform the necessary lock for multithreading
> so as to prevent the thread from inserting while main thread is reading it.
>
> And that's it. The sending part will be in the main thread. The network
> thread only concern about receiving packets.
>
> So the big question is, is the design okay?
>
> TIA.
>
>
>
> _______________________________________________
> 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/20100205/b33c4fa7/attachment.htm>


More information about the ENet-discuss mailing list