[ENet-discuss] Reliable sends, part 2

Dizan Vasquez dichodaemon at gmail.com
Wed May 11 05:42:43 PDT 2005


This is  handled by the enet_protocol_check_timeouts function but,
anyway, when a reliable command times out, it is the whole peer which
gets disconnected. That means that the enet_host_service function will
return you an ENetEvent having its type set to
ENET_EVENT_TYPE_DISCONNECT and its peer field set to the peer you are
trying to communicate to.

Dizan

On 5/11/05, Gregory Hassett <greg at hassett.com> wrote:
>  
>  
> 
> Hi, Dizan explained the following as a method for a sender to determine when
> a reliable packet has arrived at its destination (and been acknowledged). 
> 
>   
> 
> "Pease take what I say with a bit of salt. I think that you should look into
> the corresponding peer's sentReliableCommands and outgoingReliableCommands
> lists. Those lists contain EnetOutgoingCommand elements having a packet
> field. If your packet appears in one of those lists then it hasn't been
> acknowledged yet." 
> 
>   
> 
> I looked into the routine enet_protocol_handle_acknowledge
> in protocol.c, and it appears that this routine removes a command from a
> (sending) peer's "sentReliableCommands" when the destination has ack'ed the
> packet.  At this point I can be sure that the packet has arrived. 
> 
>   
> 
> I can't seem to find a corresponding location where the command is removed
> if it has timed out or otherwise failed to reach its destination.  Can
> someone with more knowledge of enet internals advise me on where I could
> "trap" to determine that a message has failed to reach its destination
> (after the last attempt times out)? 
> 
>   
> 
> Thanks! 
> 
>   
> 
>   
> 
> Greg 
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
> 
> 
>



More information about the ENet-discuss mailing list