Opt-in feature for more than 64 channels per message type

[Inurias]

I understand that 64 channels is enough for most users, but my game sometimes requires more than 64 channels when a lot is going on (many people shooting etc.) which can result in many replicated entities and more than 64 channels being opened. Unreal Engine supports a default maximum of 2048 actor channels for this reason.

I saw that there is a custom fork by @aienabled that enables more than 64 channels by using a ushort. If possible I want to avoid maintaining a custom fork for this functionality.

It makes sense you don't want to increase the header size for all users. I want to ask if it is possible for users who need this functionality to opt-in to this feature, so that all the users have the 1 byte and 64 channels limit by default but users who need more can increase this limit if needed. This way, only the users that need it will have more than 1 byte.

[RevenantX]

@Inurias most source/unreal like game engines use unreliable for almost all messages. When you need more channels this can be sign of strange architecture

[Inurias]

@Inurias most source/unreal like game engines use unreliable for almost all messages. When you need more channels this can be sign of strange architecture

Right now it's all just a prototype and my networking is not done yet. You might be right, most bigger games probably open and close channels on-the-fly to avoid too many reliable entities at once. Although I think many games might have more than 64 reliable actors at once (thinking Fortnite etc.). I don't have any official data to back it up.

If it's not too much work, I think it would still be nice for users to have it as an optional feature for the cases where it is required.

[RevenantX]

@Inurias they don't use reliable channels. Reliable channels can be used for send initial data. Later engine sends unreliable packets with ticks inside (look at Source(engine by Valve) documentation). And sending delta between frames based on received ticks.

[Inurias]

But if it's based on received ticks and sending a delta, in order to calculate a delta you need some sort of acknowledgement, otherwise how do you know it was received? In which case it should be some reliable delivery type. Property replication in Unreal Engine is also reliable (see https://docs.unrealengine.com/4.27/en-US/InteractiveExperiences/Networking/Actors/Properties/).

[RevenantX]

@Inurias when you send inputs from player you also send last received (and interpolated) server ticks - this will be your acknowledgement. Same from server when you send delta to player you include latest received/processed input back to player (so player can remove buffered past inputs)

[Inurias]

I am still working on the networking so I can't say for sure if everything will work out perfectly, but after some refactoring I don't need more than 64 channels at the moment. But I have another problem mentioned in (#406), what if I want to send data (reply) via the same channel that some data was received on? For example I have a channel that only does entity lifetime networking (spawning and destruction). Of course if in the code I look into my packet I theoretically already know which channel it was sent from, but wouldn't it be cleaner to have this info on the receiving end dynamically?

[RevenantX]

@Inurias in latest LiteNetLib there is channel info in receive method:

        /// <summary>
        /// Received some data
        /// </summary>
        /// <param name="peer">From peer</param>
        /// <param name="reader">DataReader containing all received data</param>
        /// <param name="channelNumber">Number of channel at which packet arrived</param>
        /// <param name="deliveryMethod">Type of received packet</param>
        void OnNetworkReceive(NetPeer peer, NetPacketReader reader, byte channelNumber, DeliveryMethod deliveryMethod);

[Inurias]

Awesome, I switched to the pre-release version. Thank you! I will close this issue as soon as I'm done with the replication code, if that's ok with you.