ruk33/l2auth

Lineage 2 C4 server written in C as a learning exercise

l2auth's Issues

Server receving new connections but not able to log into the game

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.

One db connection for the entire world?

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:

• The db connection is guaranteed to be open and ready to accept queries
• It should be more performant (although this is not really that important, number 1 is the big deal)

Besides pros, I don't see any cons (at the moment)

Documentation - Movement and state machine

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:

• All actions that modify state must go through a state machine to prevent invalid states
• All actions are queued up and then processed one by one.

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.

login with invalid credentials

Steps to reproduce:

• login with valid credentials
• go back to login screen
• without changing the username, put any password (invalid)

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)

Dealing with database failure

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.

Documentation - Threads

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?

One thread for the entire server

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.