[ENet-discuss] Sending data when the host is waiting for time-out

[Chris Cochran]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20140214/90dd6a30/attachment-0001.html>