Don't use the timeout. Pass in 0. ENet is really meant to shine when it is used in a normal fame loop, called in a non-blocking fashion at the beginning of each frame. So in this manner of usage, you will never catch ENet with its pants down and there is no real problem. Even then, ENet is meant to aggregate sends, so if you're trying to get "immediate" send behavior you're not really playing nicely with the batching anyway.
On 02/14/2014 10:43 PM, Chris Cochran wrote:
We currently use ENet to provide an internal networking layer for a C++ multithreaded concurrency framework. ENet is well-conceived, and has all speed, simplicity, functionality, and sensible design we were looking for. As others have pointed out, there is a limitation with enet_host_service( ) blocking on receive when you have things to send. Our current coping solution is to dynamically reduce the receive time-out to 0 or 1 msec when host activity is active, lengthening to 20 msecs when quiescent. This approach causes a 20 msec delay for the first send( ) in a series, and generates more thread activity than desired for quiescent host threads. No adjustments to this can improve the situation. A better solution others have mentioned involves making (only for Win32) modifications to the enet_socket_wait function to allow waiting on socket send and receive, as well as a “cancel wait” event object (using WSAEventSelect, and WSAWaitForMultipleObjects). Then add an additional function (enet_socket_cancel_wait) that signals the “cancel wait” event object and wakes the network thread. From there, the enet_host_service function immediately returns with a timeout event to process the send command. But we propose a simpler solution, to have enet_socket_cancel_wait( ) sense when a blocking-on-receive is occurring, then send a local administrative packet through that socket to release it, which when received returns an ENET_EVENT_TYPE_CANCEL_TIMEOUT. This "send" would be triggerable by any thread, and would quickly ignore additional redundant requests that occur while in flight. The big advantage of this approach is that the existing receive logic runs unchanged, without complicating it beyond recoginizing the admin packet to return a different event type. A new ENet function or option would likely be necessary, to enable this feature when desired, so that existing message loops would remain unaffected. I would be most interested in knowing the feasibility of this proposed approach, should we consider implementing it ourselves. However, we would much prefer to wait for an official ENet build that solves this pressing issue. Are there plans to resolve this limitation. Thanks, Chris Cochran
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
