[ENet-discuss] Mixing Reliable and Unreliable and Packet Ordering

Philip Bennefall philip at blastbay.com
Mon Sep 27 10:36:29 PDT 2010


My understanding is as follows (anyone correct me if I'm wrong here):

1. You'd first get the 100 unreliable packets, exactly in the order you sent them but they are not all guaranteed to arrive. You may get packets 1, 2, 3, 4, 6, but you will never get 1, 3, 2, 4.

2. Then, you'd get the reliable packet (guaranteed).

3. After the reliable packet has been received and acknowledged, you'd start receiving the remainder of the packets (which is to say the 50 unreliable ones).

In no event will you get packets in the wrong order, as this is exactly what ENet is there to avoid. You can specify a flag to get this behavior though, if you want it for whatever reason.

Hope this helps.

Kind regards,

Philip Bennefall
  ----- Original Message ----- 
  From: Nicholas J Ingrassellino 
  To: enet-discuss at cubik.org 
  Sent: Monday, September 27, 2010 7:20 PM
  Subject: [ENet-discuss] Mixing Reliable and Unreliable and Packet Ordering


  I know I could use different channels to get the result I want but I was curious about the expected behavior using a single channel.

  Suppose if I had sent 100 unreliable packets, followed by one reliable packet, followed by 50 more unreliable packets. In what order should I expect them to arrive?

    a.. Would I first get the 100 unreliable (in any order, if at all), followed by the reliable, follows by the 50 unreliable (in any order, if at all)? 
    b.. Would I get these 151 packets in any order with only the reliable one guaranteed to arrive? 
  I am also under the impression that the second batch of 50 unreliable packets would not start to arrive (if at all) until after the one reliable one has arrived?



------------------------------------------------------------------------------

  Nicholas J Ingrassellino
  LifebloodNetworks.com || nick at lifebloodnetworks.com

  "The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying."
  - John Carmack on software patents
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20100927/6fe33391/attachment.html>


More information about the ENet-discuss mailing list