Refactoring to asynchronous.

[BruceChenQAQ]

(Unfinished)

• Rewrite most of the code to be asynchronous.
• Performance optimization for packet reading (decompression and AES decryption).
• Use hardware accelerated AES instructions for supported Arm devices. (not tested)
• Change to save the session cache and signature key cache as a json file.

[BruceChenQAQ]

Plan to move the protocol library to a separate repository.
This repository will be transferred to the MCCTeam organization prior to this PR merge.

[milutinke]

@BruceChenQAQ Are you planning on finishing this?
If not, what is left to be done, so we can finish it?

PS:
Also, I made a nice way to handle packets, you could bring my code in to the branch and wire it up with your changes to packet data reading.
Read the #todo channel on discord to catch up with it.
https://github.com/milutinke/Protocol-Lib-Prototyping

[milutinke]

PS:

public async Task<bool> SendBrandInfo(string brandInfo)
{
   return await Task.FromResult(false); //Only supported since MC 1.7
}

Task.FromResult results in Task allocation on the heap, use ValueTask<T>(data) instead.

Maybe await Task.WhenAll in cases like this?

 private async Task ReadNextTeamData()
        {
            await ReadNextString(); //Internal Name
            byte mode = await ReadNextByte();

            if (mode == 0 || mode == 2)
            {
                await ReadNextString(); //Display Name
                await ReadNextString(); //Prefix
                await ReadNextString(); //Suffix
                await ReadData(1); //Friendly Fire
            }

            if (mode == 0 || mode == 3 || mode == 4)
            {
                short count = await ReadNextShort();
                for (int i = 0; i < count; i++)
                {
                    await ReadNextString(); //Players
                }
            }
        }

[BruceChenQAQ]

@BruceChenQAQ Are you planning on finishing this? If not, what is left to be done, so we can finish it?

PS: Also, I made a nice way to handle packets, you could bring my code in to the branch and wire it up with your changes to packet data reading. Read the #todo channel on discord to catch up with it. https://github.com/milutinke/Protocol-Lib-Prototyping

I may not have much time to finish this recently, but I can post the previously completed part. Note that this contains only part of the framework structure and part of the packet parsing, it is not finished and cannot be compiled yet.

My intention is to be compatible with different types of protocols in the library and to allow multiple instances of clients to be created at the same time (no matter what protocol type or version they are) and for them to run without affecting each other. (Of course in MCC only one instance may be running at a time)

To do this I need to carefully find for each packet the version in which it has changed (including naming changes) and distinguish it in the protocol library.

Here's a couple of pieces of code that are close to completion, so maybe you can get a general idea of what I'm thinking:

\MinecraftProtocolLibrary\JavaEdition\PacketHandler\PacketPattle\PacketPalette_1_19_2.cs

\MinecraftProtocolLibrary\JavaEdition\PacketHandler\ClientToServer\ClientCommand.cs

\MinecraftProtocolLibrary\JavaEdition\PacketHandler\ServerToClient\SpawnEntity.cs
\MinecraftProtocolLibrary\JavaEdition\PacketHandler\ServerToClient\BlockEntityData.cs

MinecraftProtocolLibrary.zip

[milutinke]

@BruceChenQAQ Are you planning on finishing this? If not, what is left to be done, so we can finish it?
PS: Also, I made a nice way to handle packets, you could bring my code in to the branch and wire it up with your changes to packet data reading. Read the #todo channel on discord to catch up with it. https://github.com/milutinke/Protocol-Lib-Prototyping

I may not have much time to finish this recently, but I can post the previously completed part. Note that this contains only part of the framework structure and part of the packet parsing, it is not finished and cannot be compiled yet.

My intention is to be compatible with different types of protocols in the library and to allow multiple instances of clients to be created at the same time (no matter what protocol type or version they are) and for them to run without affecting each other. (Of course in MCC only one instance may be running at a time)

To do this I need to carefully find for each packet the version in which it has changed (including naming changes) and distinguish it in the protocol library.

Here's a couple of pieces of code that are close to completion, so maybe you can get a general idea of what I'm thinking:

\MinecraftProtocolLibrary\JavaEdition\PacketHandler\PacketPattle\PacketPalette_1_19_2.cs

\MinecraftProtocolLibrary\JavaEdition\PacketHandler\ClientToServer\ClientCommand.cs

\MinecraftProtocolLibrary\JavaEdition\PacketHandler\ServerToClient\SpawnEntity.cs
\MinecraftProtocolLibrary\JavaEdition\PacketHandler\ServerToClient\BlockEntityData.cs

MinecraftProtocolLibrary.zip

That is quite a lot of work you've done, I like it, it is very similar to what I've proposed in one of the issues, using events and custom classes for parsing packets.
Maybe you could use Reflection to load in packet classes automatically like I have done in my repo, and then call methods that would have attributes with version, this would be less typing, but it could not be compiled to native code with new .NET 8 native AOT feature.
As for getting the list of changes per version, a good resource on that is the PrismarineJS/minecraft-data
When you get the basic version that can be compiled and is working, push the code to your repo, I'll create all the packets.

[milutinke]

Maybe if you can, push the code to your repo, I'll add packets that we already have implemented.
And I'll make a tool that uses minecraft-data and displays the code for each packet for each version side my side.
Maybe I could even make a code generator from it, so we don't have to type that much.

[milutinke]

@BruceChenQAQ Any updates on this?