[ENet-discuss] Removing Channels and Reliable Ordering

Jim Purbrick Jpurbrick at climax.co.uk
Mon Nov 17 11:11:25 PST 2003


Thanks Lee.

I now seem to have a working ENet mod with no channels and no stalling of
reliable packets.

> Oh, I get you now! Well, in a way I'm almost tempted to support
> unsequenced (un)reliable packets, but am not sure how much the
> extra code would muck up the internals. Though, if there is a 
> strong need from enough people, I could accomodate it.

No stalling seems to be a one-liner.

Line 197 in peer.c:

        if (incomingCommand -> fragmentsRemaining > 0 ||
            incomingCommand -> reliableSequenceNumber > channel ->
incomingReliableSequenceNumber + 1)
          return NULL;

Becomes:

        if (incomingCommand -> fragmentsRemaining > 0)
          return NULL;

You could stick a bool in the peer or host which enables or disables this
check easily enough.

> But more or less, you would have to add two incoming command queues
> (one for unreliable, one for reliable) on the peer. You would still
> need to keep the reliable sequence numbers for identifying packets
> during acknowledgement. enet_peer_receive() would need to be rewritten
> to scan the two queues for any completely assembled packets. Finally,
> you could just get rid of the channel ids and channels entirely. That 
> would be about it. Shouldn't be too difficult.

The only other thing I needed to do was set the
incomingReliableSequenceNumber of the peer to the sequence number of the
connect message in enet_protocol_handle_connect.

I'll let you know how my testing goes tomorrow.

Cheers,

Jim.


More information about the ENet-discuss mailing list