Hello,
I am making a alternate server for Craft to replace the supplied server written in Python. I already started working on a prototype, but it's a mess, so I'm going to do a redesign.
Anyway, one of my largest questions here is whether I should use Async IO or not. The game is realtime, but it's only a Minecraft clone (without PVP), so speed isn't... critical.
I realize that async can make for a theoretical speed improvement for any IO operation that blocks and wastes valuable processing time. However, this game has super thin server - with almost no server logic. The server is almost just a "relay" that connects a bunch of thick-clients together by sending incoming packets out to the players. The only heavy lifting it does is querying from a SQLite database with the world in it.
So, for an application that is designed for IO (and not much else) does Async just add a bunch of closure allocations with little return, or does it make for a really nice decrease in latency?
PS: I also realize that this is a very general question, I'm not sure what info you might need to answer. If you need more details, let me know.
PPS: I would benchmark this, but it'll be hard - because I'd have to design the server somewhat differently twice.
That's a good point that I hadn't considered. One concern I have is that some things have to be ordered. I was having some trouble with non-determinism of the async dispatcher before. Likely it was user error :)
Still, it can be harder to reason about async code, although the syntax is super easy (WAAAY better than the low level AIO stuff in C, or even MIO/Tokio in Rust).
As for performance, I wouldn't expect to see an increase, correct? The application would be single threaded and non-parallel. Since most work is I/O, waiting for other I/O operations to continue the first doesn't buy much, unless particular reads or writes take a while... This isn't an application that can do other processing while we wait for I/O.
One nice thing about blocking IO is that it fits nicely with threadpool. So perhaps the decision is not sync vs async, but multi-threaded vs strictly concurrent.
there also is https://nim-lang.org/docs/asyncfile.html which allows basic async file operations and there is https://github.com/cheatfate/asynctools/blob/master/asynctools/asyncipc.nim for async interprocess communication. Maybe these could also be helpful.
Regarding performance, where do you have a bottleneck right now?
Still, it can be harder to reason about async code, although the syntax is super easy (WAAAY better than the low level AIO stuff in C, or even MIO/Tokio in Rust).
Super happy to hear that :)
As for performance, I wouldn't expect to see an increase, correct? The application would be single threaded and non-parallel. Since most work is I/O, waiting for other I/O operations to continue the first doesn't buy much, unless particular reads or writes take a while... This isn't an application that can do other processing while we wait for I/O.
Without async how are you planning to handle accepting connections and receiving messages from multiple clients? You will need some form of concurrency to do, in short, these two things:
I don't think there is a way to do these without either a thread or async.
I would simply use async. If you want to squeeze as much power out of your hardware as possible then you should still use async, but in a way that allows you to take advantage of parallelism, my httpbeast project is a good example of this.
Super cool that you're making a craft server btw, will love to try it out once it's ready.
Without async how are you planning to handle accepting connections and receiving messages from multiple clients?
I was going to use the threadpool module. That way I could have one thread per client powered by a thread pool without the expense of creating new threads one by one.