[ENet-discuss] Fragmentation Problem?

[Jim Purbrick]

Cheers Lee,

I'm glad I'm not going mad. As I've modified my version of ENet and
converted it to C++ I'll have to apply the changes to my copy rather than
just getting the new version. Is the only change the queueing of a converted
copy or is there more to it than that? Is there any reason you can't convert
the values in place rather than creating a copy? Most importantly, is there
a list of known bugs and fixes that I can look at before tracking these
things down in future :-)

Thanks for all your help,

Jim.

> -----Original Message-----
> From: Lee Salzman [mailto:lsalzman at telerama.com]
> Sent: 03 December 2003 17:30
> To: Discussion of the ENet library
> Subject: Re: [ENet-discuss] Fragmentation Problem?
> 
> 
> There is a change I made about a month ago that should have 
> fixed this.
> 
> It basically queues a copy of the command ("hostCommand") which is
> filled with all the converted values, instead of the original command,
> in enet_protocol_handle_send_fragment. Is that fix in your 
> code? If so,
> then there is some more evil problem I will have to track down here.
> 
> Lee
> 
> On Wed, Dec 03, 2003 at 03:38:30PM -0000, Jim Purbrick wrote:
> > Hi All,
> > 
> > I'm having problems getting fragmentation working and have 
> found something
> > that I'd like some clarification on.
> > 
> > enet_peer_send seems to send the startSequenceNumber in 
> network order:
> > 
> > enet_peer_send (ENetPeer * peer, enet_uint8 channelID, 
> ENetPacket * packet)
> > {
> > 	<snip>
> >          startSequenceNumber = ENET_HOST_TO_NET_32 (channel ->
> > outgoingReliableSequenceNumber + 1),
> > 	<snip>
> >          command.sendFragment.startSequenceNumber = 
> startSequenceNumber;
> > 	<snip>
> > }
> > 
> > enet_protocol_handle_send_fragment then converts the 
> startSequenceNumber
> > back to host order, but compares
> > this value to the startSequenceNumber values in the
> > incomingReliableCommands, which don't seem to have been converted
> > to host order anywhere. The comparisons then fail and none 
> of the fragments
> > get reassembled.
> > 
> > enet_protocol_handle_send_fragment (ENetHost * host, 
> ENetPeer * peer, const
> > ENetProtocol * command)
> > {
> > 	<snip>
> > 	    startSequenceNumber = ENET_NET_TO_HOST_32 (command ->
> > sendFragment.startSequenceNumber);
> > 	<snip>
> >        if (startCommand -> command.header.command ==
> > ENET_PROTOCOL_COMMAND_SEND_FRAGMENT &&
> >            startCommand -> 
> command.sendFragment.startSequenceNumber ==
> > startSequenceNumber)
> >          break;
> > 	<snip>
> > }
> > 
> > I must be missing something here, but can't see where the
> > startSequenceNumbers in the queued incomingReliableCommands
> > get converted back to host order. If I comment out the net to host
> > conversion in enet_protocol_handle_send_fragment,
> > both startSequenceNumbers are in NBO and the comparison succeeds.
> > 
> > Anyone got any idea what's going on here?
> > 
> > Cheers,
> > 
> > Jim.
> > 
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
>