At 7 o'clock last night, until 11 am, it has been refactored to the lobby and the room server. The code structure after the reconstruction is clear, and the efficiency is also improved. I feel that this reconstruction process is very meaningful, so record Take it down.
In the original hall server, the original design is to use a unified Tuser object to manage the reception of the underlying data and the attribute read and write operations of the logical layer for the Tuser, whether it is the player's normal connection SOCKET or for temporary communication. Socket, as long as there is a connection, a Tuser object is assigned. In the Tuser object, it also contains information about these two aspects: one aspect of information is used for underlying data communication, such as attributes such as receiving buffers arrays, and receives buffer size; and on the other hand is logic. The player object definition of the layer, including: player account, gender, age, etc. In the original design, there is no further division of information in these two aspects, but in a uniform in a Tuser. In this way, there is a problem for some non-normal players, such as the player register or other servers, and the server communicated with the server. As long as there is a connection, it is necessary to establish a Tuser object (because Tuser has a data buffer, All data communications must be made by their respective buffers) so that some of the player properties of the Tuser object have not been used, resulting in a lot of memory space.
In the new structure, the Tuser object is divided into two. The data and methods of the underlying communication are separated, forming a new object: Tconn, TCONN is dedicated to handling the bottom communication data of each player and maintaining each player. Receiving buffers, in the RECV of Socket, the logical packets submitted to higher layers in accordance with TCONN and the received new data, and in its subsequent high-level logic, the maintenance of the TUSER object is included. . In this way, when TCONN is separated, it is required to maintain the TUSER object, and the TUSER is maintained at the logic of the high layer, while the data packets separated by TCONN are required to maintain Table or other objects. No need to load the Tuser object again. That is, the life of the Tuser object is completely on the logic of the high-level logic, not according to the network connection and disconnection, and the two objects that are divided into good areas are divided into the network underlying and game logic. Aspect, so that it can be substantially detached from each other, with better spreadability and independent.
After the reconstruction, it is inadvertently solved such a BUG: The user cannot change the status of the state in the room from the table.
