Hello again,
I've been asking a lot of newbie questions lately, and I appreciate those who have answered the questions quite thoroughly. The reason I've been asking these questions is because I'm looking to create a server for a real-time 3D video game in D (think Quake 3). The last time I attempted this, my server was hopelessly single-threaded and synchronous, so this time I'm looking to find a better approach.
The idea behind the server is quite simple:
- Client sends the server a message, such as 'shoot gun' or 'move forward'
- The server takes this message and sends it to be processed by a thread which has the least work (a metric which is often hard to figure out)
I've got a reasonable idea on how to set up a fine-grained system of locks for this architecture, and it allows for good load balancing and avoiding a set number of threads. Some server architectures go for one thread for collision detection, one thread for ..., etc. which creates a set number of threads and poor load balancing, which is what I'm looking to avoid.
However, it looks like vibe-d may not be a good candidate for this kind of architecture:
- The server operates on UDP, and unlike TCP, I don't have a bunch of connections to worry about. I just accept datagrams. It's enough to have one
listenUDP. - Each message received by the server will create an operation that is quick (no yielding) and needs no sleeping. Such as tracing a bullet path or changing an entity's location.
- There is little to no I/O going on beyond receiving UDP datagrams.
Now as I understand, compared to just throwing around function pointers/delegates, the advantage of using Fibers in this architecture is that it makes it easier to debug.
Can someone clarify my assumptions or recommend why vibe-d might be a better fit than I think, or recommend another approach?
Thanks,
Kelet