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

Olivier Delannoy olivier.delannoy at gmail.com
Fri Feb 5 00:46:53 PST 2010


On Fri, Feb 5, 2010 at 8:14 AM, Syed Setia Pernama <syedhs at yahoo.com> wrote:
> I am using Intel VTune profiler and the hits ~20% was in the function
> enet_protocol_dispatch_incoming_commands.
> I think the reason why enet is taking much of the processing time because
> first
>
> 1) it receives the packet from up to 5 clients (which send @60hz, and each
> of them is about 1kb-2kb, so each second it receives up to 120kb per
> client). The packet size received is just my estimation but I tried not to
> exceed the MTU max size.
>
> 2) and then it will retransmit some of the packets back to all clients.
>
> I have a dateline this tuesday to have stable server and to have a stable
> one, the most crucial thing is to have server running the physics @60hz. I
> think without mult-threading, it is not possible. Anyway, I will post my
> findings once the code is working.
>
> I think this could be interesting as CPU dice scales up (quad-core,
> eight-core etc) and I dont think multi-threading enet is that difficult as
> the enet can keep most of the data to iself (hence, the thread it is running
> on).
>
RakNet behaves that way. It provide a "enet-ish" layer and add an
another level of abstraction that provide an event dispatcher. The
event dispatcher manage the udp socket in its own thread.

> ________________________________
> From: Blair Holloway <thynameisblair at chaosandcode.com>
> To: Discussion of the ENet library <enet-discuss at cubik.org>
> Sent: Fri, February 5, 2010 6:39:40 AM
> Subject: Re: [ENet-discuss] Multi-threading ENet the easy way...
>
> 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
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>



-- 
Olivier Delannoy
Website: http://olivier.delannoy.dalfy.org/


More information about the ENet-discuss mailing list