| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
There was a small problem with how we computed the size of the
packet "header". It was unlikely to manifest tho, because it's at
the beginning of a TCP message and TCP segments aren't that small,
unless the whole message is that small.
I'm also allowing login servers to query for world information
to allow a basic form of `STATUS` to be implemented.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The monotonic uptime was used exclusively with caches and having
a resolution of SECONDS allows it to be stored as an int without
risk of wrapping (~68 years). Using MILLISECONDS meant that it
would wrap after ~25 days which is totally possible and EXPECTED.
Just as an example, the small test server I ran for about 1 month
had ZERO downtime on the QueryManager except for when I manually
restarted it. It was probably very close to wrapping when I took
it down.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
With this change the game server is able to login again but we
still need to re-implement/re-fit the other queries for it to
properly startup.
|
| | |
|
| |
|
|
|
|
| |
This moves queries from `src/connections.cc` to `src/query.cc` and
adds a few missing details. The only thing left is to review query
processing and tie database operations to the `TDatabase` struct.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I had just added it in the last commit but it made its use case
non-obvious. Checking whether the string is empty before trying to
parse an IP address is clearer than calling some function that has
its own concept of what an empty address is.
|
| | |
|
| |
|
|
|
|
| |
There was a problem with concurrent writes not being visible
until after restart, due to how cached prepared statements work
with SQLite (see comment in `database.cc`).
|
| |
|
|
|
|
|
|
|
| |
- Add support for SIGINT and SIGTERM signals for graceful termination.
- Properly check premium account status with `EVICT_FREE_ACCOUNTS`
query.
- Properly check if character is already online before failing game
login with "too many characters" error.
- Overall cleanup.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
This is a bare bones query manager that will respond just enough
queries to get the server running. The overall structure of the
tables should be almost set but we'd need to handle all queries to
get the server running properly.
It uses the SQLite3 3.50.2 amalgamation for a database backend so
we can completely avoid having to spin up yet another service for a
separate database system, effectively turning the query manager into
the database itself. This also means that other services such as the
login server and website must go through it to access the data but
it shouldn't be too difficult to replicate the querying mechanism
from the server.
This design choice was made with a single game server in mind. The
networking protocol is NOT encrypted at all and won't accept remote
connections. For a fully multi-world distributed infrastructure, a
distributed database system like PostgreSQL and MySQL should be
considered.
|
