search

lnobad / lidgren-network-gen3

Automatically exported from code.google.com/p/lidgren-network-gen3
0 stars 0 forks source link

Partially received fragmented messages are retained in received memory #65

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Send a large message via NetUnreliableSenderChannel
2. Make it large so that it will be fragmented
3. Make it really large so that the some fragments will be dropped in 
NetUnreliableSenderChannel.Enqueue(NetOutgoingMessage)

What is the expected output? What do you see instead?

Perhaps it is the expected behaviour, but when a fragment message is dropped in 
an unreliable channel, the message is never fully received at the receiver, and 
the fragments that were actually sent are forever retained in 
NetPeer.m_receivedFragmentGroups on the receiver. This results in ever 
increasing memory consumption on the receiver.

What version of the product are you using? On what operating system?
Using r195 of lidgren-network-gen3 on Windows 7 64 bit.

Please provide any additional information below.

Original issue reported on code.google.com by alexande...@gmail.com on 3 Apr 2011 at 11:46

GoogleCodeExporter commented 9 years ago 
Yes; this is correct. Unreliability and fragmentation is a bad mix; I'm not 
sure if I will disable it altogether or fix some sort of timed cleanup.

Original comment by lidg...@gmail.com on 19 Apr 2011 at 6:37

GoogleCodeExporter commented 9 years ago 
I seem to be having this same problem even when using a reliable channel. See 
http://stackoverflow.com/questions/7313829/why-does-my-simple-lidgren-client-use
-so-much-memory.

Original comment by jim00...@gmail.com on 6 Sep 2011 at 2:34

GoogleCodeExporter commented 9 years ago 
These are related, but different bugs. The stack overflow question highlighted 
a bug that meant nothing were EVER released; thanks for a great repro, the bug 
is now fixed in revision 258.
This issue however still stands as it's written... if a fragment is dropped it 
will not be cleaned up... I'll try to fix this in a later revision.

Original comment by lidg...@gmail.com on 6 Sep 2011 at 3:32

GoogleCodeExporter commented 9 years ago 
That seems to resolve the issue in my test program. Thanks!

Original comment by jim00...@gmail.com on 6 Sep 2011 at 8:43

GoogleCodeExporter commented 9 years ago 
I am having issues with memory consumption directly related to network use on 
an application that I have inherited and causes the application to run out of 
memory. 

Has any progress been made toward this issue or could you point me to the 
appropriate places in code so that I may begin working on a patch?

Thanks

Original comment by mwoo...@gmail.com on 28 May 2013 at 8:59

GoogleCodeExporter commented 9 years ago 
As stated; you should avoid sending unreliable messages above MTU. 
Fragmentation code is contained in NetPeer.Fragmentation.cs - if you want to 
verify this is the issue you're having, examine m_receivedFragmentGroups to see 
if it contains an excessive amount of data.

Original comment by lidg...@gmail.com on 29 May 2013 at 7:37

GoogleCodeExporter commented 9 years ago 
Can't this be quite easily abused to DDOS any server using Lidgren ?

Original comment by luna.duc...@palmstonegames.com on 14 Nov 2013 at 4:33

GoogleCodeExporter commented 9 years ago 
Possibly. I'll consider prohibiting sending unreliable messages above MTU... or 
just omit fragmentation and send the message as a single packet regardless of 
MTU.

Original comment by lidg...@gmail.com on 10 Oct 2014 at 8:01

GoogleCodeExporter commented 9 years ago 
Rev 382 contains NetConfiguration.UnreliableSizeBehaviour to decide which 
strategy to handle unreliable sends over MTU

Original comment by lidg...@gmail.com on 10 Oct 2014 at 3:35