[ENet-discuss] Channel Incoming Unreliable Commands List Management Question

[Alexander Dolgansky]

Hi Lee.

I was quite excited to see the update so fast! Thanks.

So, I've tried it out and now I can send messages that I previously
was not able to send wirelessly using best-effort delivery method. The
only snag now is that if I attempt to increase the message size (~200
fragments), I can no longer re-assemble the received messages using
either wireless and wired setup. The wired setup did work before with
the same kind of message size, so I am not sure why it stopped working
now (the wired setup did not change at all). Moreover, the increase in
message size does result in a larger bandwidth usage so it appears
that large number of packets do reach the intended target.

I wonder if I am hitting the limits of what I can send unreliably but
again it did work with the wired setup. Also, sending the same message
back to back results in only the first message being successfully
processed by ENet. Slowing down the sending rate for larger messages
doesn't seem to help either so it almost feels like that once fragment
count reaches certain value, messages begin to disappear continuously.
This is just my speculation. I did notice that unreliable sequence
number is only two bytes long but that will mean that a message will
need to be partitioned into more than 65535 fragments to cause an
overflow in the sequence number. I don't believe I am anywhere close
to that number of fragments per message, so overflow is likely not the
issue.

I would like to pursue this issue a bit more to see if there is still
an undiscovered ENet bug or if I've reached the limit of what I can
send using the unreliable fragment option.

Alexander.