Packet encapsulation #9052
Motivation / Problem
The pointers and state of the Packet class are updated by other functions all over the place. This makes further changes more difficult as the logic for packet size and reading/writing location is spread all over the network code.
The major benefit at the end is to make it much easier to introduce larger packet sizes, a big first step is in https://github.com/rubidium42/OpenTTD/tree/bigger_packets which makes OpenTTD accept (TCP) packets up to 32767 bytes, and uses that size to send save games as well as to the content server (which is not limited by the current MTU). Later changes could then also be done for e.g. receiving data from the content server or certain admin commands. However, that requires changes to the protocol to determine whether the other side accepts such large packets which is beyond the scope of that patch.
Removes all the direct access to the state variables of a Packet.
Any patch messing manually with the Packet state will be broken.
Technically it is possible to extend the Packet size even more, but for save games it does not seem wise to send even larger packets as then it will also take longer before we start with sending data.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.
The text was updated successfully, but these errors were encountered:
…rite data into the Packet
…vent packet state modifications outside of the Packet
…buffers to prevent packet state modifications outside of the Packet
…om a buffer in to a Packet
…nternal state of Packet private