[Suggestions] Some useful suggestions about this project

[Misaka-Nnnnq]

Really glad to see this project growing so fast and already achieving some impressive results.
I went through the code briefly and wanted to share a few small suggestions.

Unfortunately, due to some health issues and being tied up with other game security projects,
I’m not able to open a PR for this myself right now.

---

1. About Mutex usage

The use of mutexes can potentially reduce Go’s natural concurrency advantages.
It’s not a major issue though—modern mutexes are extremely lightweight, and you’d only see a slight performance drop when handling tens of millions of connections.
For FSD, this is totally fine.

Still, it can be improved.
For example, when synchronizing data between components, you could try using a Double Buffer pattern instead.

---

2. About packet handling

Ideally, the server should parse all incoming packets before forwarding them.
Handling and forwarding them directly at runtime isn’t a very clean approach.

Also, try to avoid accessing raw data like data[x] inside your handler functions—it makes future maintenance and upgrades much harder.

Consider creating a dedicated parser class for each packet type and defining an interface like IFSDCommandPacket.
You can take a look at swift-project for reference.

---

3. About voice packet forwarding (UDP)

I noticed you’re using plain UDP for forwarding voice packets.
While it’s clear this is just for testing and not production, I’d still like to point out that this method introduces significant vulnerabilities.

For a basic voice server, you should reorder and merge packets from different senders on the server side based on timestamps.
That’s just the starting point—there are plenty of other things to consider, most of which you can easily find documented online.

Additionally, having a TCP fallback for voice data is very important, especially in regions with unstable or restricted network environments.

---

I really appreciate all your contributions to the open-source community.
Keep up the great work, and best of luck with the project! 🚀

[half-nothing]

Overall, the project is currently in the testing phase.
First, ensure that all functions are correctly implemented, and then refactor the required modules.
You can see this in the commit. I have carried out many refactoring operations.
Although this may lead to repetitive development work, for agile development, refactoring is also an important part of it.

For the first suggestion:
For modern computers, the overhead of mutex locks can be ignored.
I have tried my best to ensure Go's high concurrency advantage, but in some places, using mutex locks is indeed a simple and effective solution.
It doesn't require too much code, won't cause too much performance loss, and won't increase the complexity of the project too much.
So it won't be the first to be considered without a clear determination that it is a performance bottleneck.

Regarding the second suggestion:
Actually, the current package processing flow is the second version after refactoring. The first version is more primitive(XD).
In a word, your suggestion is very useful and it is indeed within my consideration range.
However, I have been busy with other development projects recently, so the priority of this one is not high.

For the third suggestion:
Since I personally have no experience in designing voice servers, I have been exploring others' designs while trying to incorporate some of my own ideas. Thank you for your suggestion.