Understading a server, (forgottenserver/opentibia/C++ codebase)

[Dhust]

Hello guys, this is my first post, sorry for any mistake.
I'm experienced in C / C++ /ASM x86 and x64 / .net C#..., well, in general programming
So I'm studying the forgottenserver code, Its very organized and beautiful code.
But I have little experience in WEB/ servers / databases...

My question is: How does the server process the request of tibia clients?
I mean, let's suppose this function: authenticateAccount (SomeType accName, SomeType accPassword);
This is supposed to execute every time a client tries to log in in the user's account, but how the SERVER treats multiple requests when many clients are requesting these processes.

Sorry for my ignorance, I may be getting it all wrong, as I've said: I've no knowledge in servers.
I would appreaciate any material to study the server behavior (like forgottenserver) with clients.

 

[Dnomyar]

I guess you could make a question in the issue page of the forgottenserver in github at https://github.com/otland/forgottenserver/issues, because this is more of a internal-code related. Probably Mark will mark this as a [question] label, and will answer you at this very level of the core of C++.

 

[Dhust]

I guess you could make a question in the issue page of the forgottenserver in github at https://github.com/otland/forgottenserver/issues, because this is more of a internal-code related. Probably Mark will mark this as a [question] label, and will answer you at this very level of the core of C++.

Thanks for answering. I've avoided creating an issue in opentibia or forgottenserver github pages, because I won't add some server software generic question in
their workflow. But if I do not find a clarification here, that must be the way to go. Thank you.

 

[Non Sequitur]

TFS has a lot of concurrent programming going on, that is the reason you will see a lot of mutexes throughout the code, as I'm sure you know, they provide thread safety by preventing that multiple threads access the same resource at the same time.

TFS uses Boost.Asio to asynchronously handle network requests, you can see that happening here, what that line means is, "whenever there is a new connection, call this function". OK, now we know that whenever there is a new connection, ServicePort.onAccept will be called and will then call Connection.accept.
The Connection class uses Asio to read data from the socket, constructing the packets that will be passed to a Protocol for parsing. Reading data from the socket is done asynchronously by Asio: Connection.accept tells Asio to read NetworkMessage::HEAD_LENGTH bytes from the socket and whenever that happens, call Connection.parseHeader, which then reads the rest of the packet and calls Connection.parsePacket, which finally passes the packet to a Protocol class that actually understands it and will decide what to do next.

If the player is trying to log in his account, ProtocolLogin is used to parse that packet and answer accordingly (e.g disconnect the client if the account name and password mismatch or send the account's character list). However, if the packet was sent due to a player action (e.g moving, using items, speaking, attacking etc), ProtocolGame is used instead.

 

[Dhust]

Thank you very much, awesome explanation on TFS / boost::asio.
So when there's a new connection the TFS can create a new thread to process those requests from that new connection.
but when it can't create new threads any more and is still recieving multiple connections requests:
does it put the connections information (requests) in a row and executes by arriving order?

man... thinking of it that way, even small MMO servers must be a really expansive hardware and fast software.
Imagine 100 players hunting on some server , everyone doing reads and writes to the server's map
killing monsters and etc... I just couldn't figure out how can a mid budget PC handle that, even using
multiple threads...

 

[Non Sequitur]

The Asio dispatcher runs in one thread, however I can't tell you if it spawns other threads to invoke the callbacks passed to it, I don't think it does but you would have to look up the implementation details to know that for sure. And no, requests aren't queued per se, they will be dealt with as fast as your computer can read the data that is coming through the connection socket.

 

[Dhust]

Ok. Thank you.