Another problem with unreliable fragmented messages

[David Almroth]

Hi master Lidgren,

I think I have found another bug with unreliable fragmented messages:

If an unreliable fragmented message, sent as two fragments, arrives at
a client and one fragment is lost over the network there is a
potential bug in the code.

The problem is this:

1. The fragment that did arrive is saved as fragment ID 1 fragment
number 1, but never released because the other framgenet with number 2
will never arrive. m_fragments.Remove(id) will never be called for
the stored fragment.
2. The session will continue without problems until 65535 (ushort max)
fragmented messages has been received.
3. But then there will be a problem. When a fragment message with ID
nr 1 will arrive, the client will act as if already has fragment ID 1
number 1. It will discard the new fragment = wrong.
4. Finally, the game client will probably crash when the old fragment
(id1, nr1) is appended to the new fragment (id1, nr2).

Is this analysis correct?

I am not sure how to correct this problem in any easy way.
Please tell med what you think about this problem and if there is any
easy solution.

/David

[lidgren]

This is indeed correct. The solution would be to store a timestamp
with each fragment group and have them "time out", and also to raise
the number of fragment groups. Unfortunately it's quite a large fix;
and since the impact is minimal (sending fragmented unreliable
messages isn't really a great idea in the first place) I will not fix
it for this version. I will however make sure it's fixed in the latest
release.

--michael

[David Almroth]

Thank you.

I corrected the problem in my game with sending large UDPs
(not fragmented) for unreliable traffic.

/David