[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