ruk33 / l2auth Goto Github PK
View Code? Open in Web Editor NEWLineage 2 C4 server written in C as a learning exercise
Lineage 2 C4 server written in C as a learning exercise
Hey Buddy, how are you? This project looks really interesting, I just wanted to check with you if this is working on your side, since I'm testing it in my local, I could set up everything, but when I'm trying to log into the game, server receive the petition but is not logging.
I'm executing it in Linux environment.
Regards,
Valentino.
These are some notes I was thinking about and don't want to lose.
All actions must go through a state machine, otherwise, we may end up with an invalid state or having to make multiple checks before performing an action (ie, attack).
Having said that, we may also want to implement a work queue, but not just for client requests and timer ticks, but for every possible action performed from the server-side. For instance, say we want an NPC to start walking. Instead of immediately notify all the characters close to that NPC, we could add that action (think of it like the server is building and sending a request to itself as the clients do) into a work queue and later process it.
This should, in theory, be easier to reason about, and also, we should be able to split servers up. Why would we want to split servers up? Assume we have 100 players and 100 NPCs. For the server, you will have 200 characters (notice no distinction) all being the same and being processed. It may be good to have a server dedicated just for players so all resources are dedicated to that. I think this is similar to what the original l2off servers do.
In summary:
client request -> goes to queue
timer tick -> goes to queue
server-side action (ie, NPC starts to walk) -> goes to queue
while (1) {
process from queue
}
Server requests will be the same requests the clients send. So we will have to implement a some_request_to_packet where it converts a request back to raw bytes.
Since I'm strongly leaning towards using 1 thread and 1 request at a time, it would be safe to use just one database connection for the entire lifetime of the server.
The benefits of this are:
Besides pros, I don't see any cons (at the moment)
Steps to reproduce:
Current behavior
Users can login with invalid credentials
Expected behavior
Users shouldn't be able to log in with invalid credentials (even if they put it right the first time)
Any database query can fail so how should we deal with this scenario? or even better, how could we completely avoid it?
Like memory allocation for instance. Instead of praying to god that malloc won't fail, we simply allocate a huge chunk of memory at initialization, if it works, we continue with the execution of the server and we start to use that memory, knowing that it won't fail since it's already there and reserved for us.
Threads can be hard and very easy to be misused. Especially if locks and releases are all over the code.
In order to avoid complexity, each thread will be in charge of accessing and updating its own resources.
For example:
We may have a thread for characters that will deal with players and NPCs.
We may also have a buffs thread that will deal with the ticks of each buff. Assume there is a buff that takes 5 life points out of a character every 10 seconds. Instead of the buffs threads directly updating the character's life, the buffs thread will add a new request into the work queue so that later, the character's thread can pick it up and perform the required updates.
Each thread will be constantly checking in the work queue to see if there is a request to be handled by it.
The work queue is documented in another issue and there will be a lock/release for every queue/dequeue.
My main concern with this approach is that we may not use the computer's resources to their fullest. How many threads are per core? how many threads will be idle doing nothing?
Also, how should each thread read another's threads resources? would it be "good enough" to just read and accept the fact that we may be computing values based on old state?
Keeping up with these documentation issues, I was thinking of switching to use only one thread for the entire server and handle everything from the work queue. The pro of this being obviously, easier to work and correctness. On the downside, we may be losing some performance although, we don't really know if we truly need threads for the time being.
After measuring, and only if we do, I would like to implement threads at the very minimum only in places we need it. Very similar to how the work queue is implemented. We know the only thread lock is located in that part of the code and nowhere else.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.