On Wed, Oct 24, 2012 at 10:13 AM, Stefan Lundmark <[email protected]> wrote: > Exposing the sleep amount time might be a good idea considering 200 ms makes > it totally useless for anything that needs to run in real-time, like games. > > Are you emitting a signal for each packet received, too?
Yes, here it's emitting the 'received' signal of QENetPeer: https://bazaar.launchpad.net/~george-edison55/qenet/trunk/view/head:/qenet/src/QENetHost.cpp#L33 Also, since the data is passed as a QByteArray signal parameter, this necessitates creating a copy of the data. To avoid this QByteArray::fromRawData could be used, but that's somewhat dangerous for a library to do since this would make it illegal for the QENetPacket (or its data) to be stored for later use unless an explicit copy is made of its data while it is still allocated (since it would be comparable to simply storing the char * and length provided by enet). That said, I really doubt copying the data and emitting a signal per message is going to be a performance concern. As for the automatic host service timer, maybe the library should just expose a 'service' method (slot) so that the application using the library can hook up a timer of its own at whatever desired frequency. I do think ENet is rather simple to use directly so for me personally such a library is not adding much. For my own purposes I wrote this ENetClient class, which is meant to be subclassed in order to implement different clients and has some protocol helpers used by the Mana client and server built into it (MessageIn and MessageOut) as well as using QHostInfo for non-blocking host lookup (I couldn't find a way to have enet do this in a non-blocking way). https://github.com/mana/manamobile/blob/master/src/mana/enetclient.cpp Regards, Bjørn _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
