RakNet InternalPacketPool & RakPeer::Send improvements and fixes #923
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new implementation of
MemoryPool
from https://github.com/facebookarchive/RakNet/blob/master/Source/DS_MemoryPool.h , to be only and ONLY used forInternalPacketPool
, by replacing the oldInternalPacketPool
class implementation with newMemoryPool
. This is because freeing and allocation new InternalPacket on memory wasn't handled properly in old RakNet, specially freeing them, resulting to many issues and crashes randomly in random occasions that we can't even figure out why.After going through samp-server disassembled code, I realized there are differences, and it's way different than just a simple
free
call ordelete
operator and it looks more like what RakNet v4 offers, so I made it use that. This can potentially fix the memory leak issue we've had since the beginning of open.mp development, that could've been only noticeable on very long runs.Second change is adding new Send functions (also RPC functions, but they're not used, because they don't matter in this case) to take an instance of
NetworkBitStream
for data, instead of passing raw data and number of bytes. RakNet has other Send functions that can takeRakNet::BitStream
and this is done because allSend
functions callRakPeer::SendBuffered
which take number of bits in your data. So using normalRakPeer::Send
function which take number of bytes and not bits, meaning it is always aligned and sends extra bits, while it shouldn't really matter on performance and bandwidth level, many servers and protection layers (like custom firewall rules) depend entirely on bit size of the data, and can fail when it's aligned to be valid number of bytes