search

springtg / lidgren-network-gen3

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

Exception: Message too large! Fragmentation failure? #68

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi,

We are just update our project from old Lidgren to gen3 (2011-02-19).

Now, sometimes we can get exception "Message too large! Fragmentation failure?".

Btw, our project can send long messages.

As i understand need set NetPeerConfiguration.AutoExpandMTU = true.
This is good solution?

Tell please, what best way to solve issue?

Original issue reported on code.google.com by IvanEfi...@gmail.com on 18 May 2011 at 9:58

GoogleCodeExporter commented 9 years ago 
No; you do not need to set AutoExpandMTU to true; fragmentation is always 
enabled. In fact, try to set it to false and you may not get those errors... 
MTU expansion is a new feature and can be a bit flakey.

Original comment by lidg...@gmail.com on 18 May 2011 at 11:22

GoogleCodeExporter commented 9 years ago 
Tried with disabled AutoExpandMTU. (disabled by default).

No any special options for Lidgren library.
So strange.

Original comment by IvanEfi...@gmail.com on 18 May 2011 at 11:41

GoogleCodeExporter commented 9 years ago 
AutoExpandMTU = True solves the problem.

But still don't know this is good way or no.

Original comment by IvanEfi...@gmail.com on 19 May 2011 at 10:09

GoogleCodeExporter commented 9 years ago 
I've also discovered this issue. It revealed when I tried to send message with 
length of 1404 bytes and my MTU = 1408. The lib choose to not fragment this 
message and then when service header is added it becomes larger than MTU which 
generates this exception.  (see NetConnection.cs, line 305).

I've solved this issue by changing the code line 49 in NetPeer.Send.cs to 
int len = msg.GetEncodedSize();
It works for me.
Is it acceptable and valid fix?

Original comment by oga...@servicerepairsolutions.com on 8 Jun 2011 at 7:02

GoogleCodeExporter commented 9 years ago 
Nice catch! I added a fix in rev 239 (and 240 made it a const) - calling 
GetEncodedSize would actually be more proper, but I opted for the more 
performant way of just adding the header size.

Original comment by lidg...@gmail.com on 8 Jun 2011 at 7:24