[ENet-discuss] Help! Simple problem with large packets

[Lee Salzman]

I put up a new tarball. It SHOULD fix this problem. The value that was
denoting the start sequence number of the fragments was not getting
converted to host endianness, but it never manifested for me because I
was doing testing on a big endian platform (PPC). 

Also has fixes for some build (thanks Scott) and connection handling issues
(thanks Weon).

Better thread support is coming soon (more props to Weon :]), by request 
of a few people. :)

On Thu, Oct 30, 2003 at 07:08:33PM +1100, Pete Diemert wrote:
> 
> Hello, this is my first time posting to enet.  First off, just want to add that ENet is definite gem of a find and much appreciated.  I downloaded the latest source from about 1 week ago and integrated the library into our application.  I have a thread that calls enet_host_service() approximately every 100ms with a mutex so that the enet_host_service() calls won't overlap the enet_peer_send() calls (some coarse grained multithread support).  We then proceed to send RELIABLE packets with no problems.  However, we notice that our large packets (approx. 1500 bytes) are not making it through.  After a little investigation I can confirm that this behaviour coincides with our crossing of the single fragment barrier.  I also confirmed that all the data seems to be sending properly from the peer and is, indeed, being received by the host (at the socket layer).  This leads to me be believe the issue is somewhere in the fragment reassembly code.  This is assuming that I haven't missed something very simple regarding large packet sizes and ENet.
> 
> I am doing this on WinXP using MSVC 6.  Any insights that might point me the right direction or perhaps some references to specific lines of code that I could watch would be greatly appreciated.
> 
> thanks,
> Pete Diemert