[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