[ENet-discuss] Problem with sending packets of certain sizes (near MTU)

Lee Salzman lsalzman1 at cox.net
Sun Sep 23 14:24:41 PDT 2007


Maybe try lowering the ENET_HOST_DEFAULT_MTU (in enet.h) value, so that 
ENet's automatic fragmentation/reassembly kicks in more readily. See if 
that helps?

Lee

Steffen Kolodziej wrote:
> Yes, I use 1.1 as far as I know. I had 1.0 before and wasn't able to 
> send any packets larger than MTU at all back then, but then I updated to 
> 1.1 and changed some other stuff.
> 
> Lee Salzman wrote:
>> Are you using version 1.1 of ENet?
>>
>> Lee
>>
>> Steffen Kolodziej wrote:
>>   
>>> Hi!
>>> I'm using enet - which I like a lot - with a basic-like programming 
>>> language called BlitzMax. BlitzMax is somewhat able to interface with 
>>> C/C++-code, but not quite smoothly. I had to write my own wrapper to 
>>> make use of it. Therefore my error may be caused by other factors than 
>>> enet, but I have no idea where else to post it.
>>> Whenever I send (reliable, not checked for unreliable) packets with a 
>>> size of more than 1356 bytes, they don't get to the recipient as well as 
>>> any other packets sent in the same direction after it. Sending packets 
>>> in the other direction still works and the connection is not noted to be 
>>> dead by enet.
>>> Looked like a MTU issue to me, but when i tried to send packets with 
>>> significantly larger sizes (~2500 bytes) they worked perfectly, so 
>>> packet fragmenting seems to work at least partly. Checking the MTU from 
>>> my PC to the server via Ping in the console returned 1492 or 1500 (???) 
>>> - not sure which one is right, but they're both quite a bit larger than 
>>> enet's standard MTU of 1400 or the packet size at which i encountered 
>>> the problem. I tried to change the server's enet's MTU, but it didn't 
>>> help either. I'm not sure if i really changed it, though, because 
>>> accessing the enet host's data fields is quite complicated through BlitzMax.
>>> I guess the problem is caused by my configuration in some way, and not 
>>> by enet, but i have no idea how to debug it and hope for some clues by a 
>>> enet expert.
>>>
>>> Thank you for the otherwise great network library.
>>> _______________________________________________


More information about the ENet-discuss mailing list