Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RakNet InternalPacketPool & RakPeer::Send improvements and fixes #923

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

AmyrAhmady
Copy link
Member

  1. 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 for InternalPacketPool, by replacing the old InternalPacketPool class implementation with new MemoryPool. 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 or delete 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.

  2. 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 take RakNet::BitStream and this is done because all Send functions call RakPeer::SendBuffered which take number of bits in your data. So using normal RakPeer::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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant